Proposal to reduce anti-bundling requirements

[Simo Sorce]

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