Re: Diagnostics for missing libraries in DSOs

[Florian Weimer <fweimer at redhat dot com>]

On 08/22/2016 05:18 PM, Andreas Schwab wrote:
> On Aug 22 2016, Florian Weimer <fweimer@redhat.com> wrote:
>
> > On 08/22/2016 04:53 PM, Andreas Schwab wrote:
> > > On Aug 22 2016, Florian Weimer <fweimer@redhat.com> wrote:
> > >
> > > > Currently, it is extremely easy to produce a DSO which links against
> > > > compat symbols at run time: Just omit a required DSO when invoking the
> > > > static linker.  As a result, the symbol reference in the created DSO will
> > > > lack a version, and will be bound to a compat symbol at run time:
> > > >
> > > >   https://sourceware.org/bugzilla/show_bug.cgi?id=20489
> > > >
> > > > This is very difficult to diagnose properly.  It can also lead to current
> > > > binaries reintroducing historic bugs which we did not want to push on
> > > > applications for backwards compatibility reasons.
> > > >
> > > > What can we do here?  Can we provide a diagnostic at static link time?
> > >
> > > ld --no-allow-shlib-undefined would turn them into errors.
> >
> > Interesting, this does look helpful.
> >
> > Would it work in practice?  Could you build a distribution with this option?
>
> It would probably fail on loadable modules.

You mean plug-ins which refer to symbols exported by the application 
with -Bdynamic?  Right.

Unfortunately, a quick check against Fedora rawhide shows that plug-ins 
(in general, not just the link-to-application kind) are a major 
contributor to missing libraries during a static link.

Florian