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: Joseph Myers <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: <binutils at sourceware dot org>, <libc-alpha at sourceware dot org>
- Date: Fri, 28 Nov 2014 00:06:09 +0000
- 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>
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).
--
Joseph S. Myers
joseph@codesourcery.com