This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: Don't output symbol version requirement for non-DT_NEEDED libs
- From: Alan Modra <amodra at gmail dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, binutils at sourceware dot org, libc-alpha at sourceware dot org
- Date: Fri, 28 Nov 2014 12:20:36 +1030
- Subject: Re: RFC: Don't output symbol version requirement for non-DT_NEEDED libs
- Authentication-results: sourceware.org; auth=none
- References: <20141127081644 dot GA20383 at bubble dot grove dot modra dot org> <54775069 dot 2090905 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1411272358160 dot 15307 at digraph dot polyomino dot org dot uk>
On Fri, Nov 28, 2014 at 12:06:09AM +0000, Joseph Myers wrote:
> On Thu, 27 Nov 2014, Carlos O'Donell wrote:
>
> > On 11/27/2014 03:16 AM, Alan Modra wrote:
> > > So, absent someone implementing a glibc fix, how about we just drop
> > > the symbol versioning for weak symbols, when their defining library
> > > won't be in DT_NEEDED? Note that if "f" above was a strong symbol,
> > > ld will still complain with "./libb.so: error adding symbols: DSO
> > > missing from command line".
> >
> > This seems like the wrong thing to do, particularly since it violates
> > the principle of least surprise. I would expect the versioned symbol
> > to stay versioned.
> >
> > What's wrong with fixing this in glibc?
>
> Actually, I think it's a linker bug not a glibc bug. If you don't link
> with a library providing a symbol you use, I don't think any information
> at all about how it might be resolved with some library you didn't link
> against should be embedded in the binary: not a DT_NEEDED entry, and not a
> version requirement. I don't think you can presume at static link time,
> with a weak undefined symbol like that, "this symbol isn't needed, but if
> defined at runtime it must have this version" (as opposed to "this symbol
> isn't needed, and might have any version at runtime", which is the safe
> assumption).
This is a quibble, but in this particular case we're talking about
a weak *defined* symbol with versioning. The definition came from a
library dependency that the user didn't specify on the command line,
which is why I call this a quibble because arguably the symbol should
be undefined. (BFD ld looks at library DT_NEEDED and loads those
libraries. BFD ld has done that for a long time, but gold doesn't.
That's why the testcase I posted works with gold; With gold the symbol
is left undefined and therefore unversioned.)
--
Alan Modra
Australia Development Lab, IBM