[Martin] > I have a number of problems following your description, so let me try > to guess. In no released version of Python, libpython is build as a > shared library. However, I'll assume that you have build > libpythonxy.so as a shared library, and that this library provides the > symbols that normally the Python executable provides. Thanks for the note! I now realize I left critical information deep in the body - I was using ActivePython as it is the only released version of Python that comes with a version built as a shared library (along with a traditional static one) > In that case, using RTLD_GLOBAL is one option. It is quite safe to use > here, since it clutters the global namespace primarily with symbols > that all start with Py; those are unlikely to clash with other > symbols. Using RTLD_GLOBAL is needed since extension modules search > the Py symbols in the global namespace; they normally come from the > executable. OK - cool. So you are saying that what I have done is reasonable (whereas I assumed it was a nasty hack :) > The other option is to explicitly link all extension modules against > your libpythonxy.so. If that is done, you can drop the RTLD_GLOBAL. > Of course, the standard build process won't link extension modules > with libpythonxy.so, since that library does not even exist in the > standard build process. Right. Notwithstanding that the distribution I used *does* have a libpython, I see that the same extension modules are used by the static and dynamic versions of the core, so therefore can't have that reference. Thanks for the info - strangely enough, it appears it is not a "problem" at all ;) Mark.
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