On Thu, 31 Jan 2002, Jack Jansen wrote: > I'm not too thrilled with dlcompat. First and foremost, it fixes > some problems for some people but may introduce problems for > others (if I understand correctly). And then there's the issue > of it not being part of the base MacOSX distribution. > > I now have a dynload_next.c (that I'll check in tomorrow) that > can behave in two ways based on a #define. > > With the define off it loads every extension module in a > separate namespace, i.e. two independent modules can never break > each other by supplying external symbols the other module > expected to load from a completely different place. > > With the define on it loads all extension modules into the > application namespace. [...] Did you see the version I posted a day or two ago: If I fixed up the #ifdef macros, you could compile that three ways (at least): Global public symbols, Private Symbols, or the dlcompat trick. ( But it uses that magic hook into the non-public API from dlcompat. ) My main requirement is the better error reporting. -- Steve
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4