On Friday, February 1, 2002, at 12:09 , Martin v. Loewis wrote: > Jack Jansen <Jack.Jansen@oratrix.nl> writes: > >> With the define on it loads all extension modules into the application >> namespace. Some people want this (despite the problems sketched above) >> because they have modules that refer to external symbols defined in >> modules that have been loaded earlier (and I assume there's magic that >> ensures their modules are loaded in the right order). > > On Unix, this is a runtime option via sys.setdlopenflags (RTLD_GLOBAL > turns on import into application namespace). Do you think you could > emulate this API? Shouldn't be a problem. I had never heard of sys.setdlopenflags(), otherwise I would have done so already. >> I prefer the new (OSX 10.1) preferred Apple way of linking plugins >> (which is also the common way to do so on all other non-unix >> platforms) where the plugin has to be linked against the application >> and dynamic libraries it is going to be plugged into, so none of >> this dynamic behaviour goes on. > > I'm not sure linking with a libpython.so is desirable, I'm quite fond > of the approach to let the executable export symbols to the > extensions. If that is possible on OS X, I'd encourage you to follow > such a strategy (in unix gcc/ld, this is enabled through > -Wl,--export-dynamic). Indeed, you link against the embedder (be it .so, framework or application) in a special way that say "this is going to be the host application". -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -
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