On 09/11/2015 04:34 PM, Carlos O'Donell wrote: >> How do you propose to resolve symbol conflicts if both the system >> library and the bundled library are loaded into the same process? The >> current ELF linking scheme lacks good support for bundling libraries >> whose exported symbols have not been mangled in some way. > If you need different versions of the same shared libraries in the same > process then you must use dlmopen to load the conflicting set into a > distinct load namespace. > > At present dlmopen is not functional for this purpose in upstream > glibc master. It is something that I'm working on fixing [1]. I looked at the Solaris documentation, and I'm not sure if it's the right use-case. This seems to provide complete isolation, and would break things like SQLite (at least older versions without file-private locks) which need process-global state. I think the real issue here is the ELF model with backwards/forwards linking and symbol interposition. Ideally, we should load each DSO exactly once, resolve object symbols only against explicit DT_NEEDED dependencies (not indirect dependencies), and make most symbols non-interposable by default. At least this is my gut feeling. This is a very difficult problem, especially at distribution scale. We currently do not perform proper symbol namespace management in Fedora (as we discussed before). Perhaps we should try to track DSO symbol namespaces first, and use that data to guide further evolution of dynamic linking. -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
