> I think bundling the sources is fine, but it should *ONLY* be a fallback > if you do not find the Expat library installed on the system. *ALWAYS* > link against a system-installed library first. I'm not so sure about that. There are many problems doing that: - if there is no shared libexpat, a static one is only usable if it is compiled either as PIC, or if pyexpat is statically linked into the Python interpreter. These conditions are impossible to test. - if the installed version of expat is older than the one we ship, I think Python should still use the included one. I think the problem you had with Apache does not apply to Python: > Apache 1.3 would get loaded and export the Expat symbols to the rest > of the process. In Python, symbols of one extension module are not exported to anything else. We would not build a libexpat.so (not sure whether Apache did), and nobody would link with pyexpat.so. Furthermore, dynloading pyexpat.so will use RTLD_LOCAL, unless that is overridden by the application (and you really have to know what you're doing when changing the dlopen flags). > Now, some *other* module is loaded and dynamically links against > /usr/lib/libexpat.so. Now you have *two* sets of Expat symbols and > crashes are going to start happening. No, that can't happen. pyexpat.so does not export its symbols (due to RTLD_LOCAL), so the other module will still use libexpat.so. Regards, Martin
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