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].
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.
Cheers,
Carlos.
[1]
http://fedora-bootstrap.osop.rhcloud.com/ (currently down?)