On Tue, 2015-09-15 at 09:41 -0400, Carlos O'Donell wrote: > On 09/14/2015 08:29 AM, Florian Weimer wrote: > > 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. > > Correct, with dlmopen you have complete isolation, but I don't understand > the SQLite issue, so if you could expand on the requirement I'm happy > to listen. > > > 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. > > I'm not sure how difficult this would be because I'm not sure how many > symbols rely upon indirect dependencies. I think it would be a worthwhile > cleanup to turn on something like you suggest, and attempt to bootstrap > the OS using Fedora Bootstrap [1]. Symbol interposition is used a lot for very useful features, blocking interposition would break a lot of stuff. > > 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. > > Agreed. We do indeed need some infrastructure in tools to extract all > symbols out of the entire distribution and review them. How do you distinguish between intentionally clashing symbol names and others ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
