Symbol versioning for secondary libraries is not effective

Symbol versioning for secondary libraries is not effective

[Florian Weimer]

I looked at underlinking issues in the upcoming Fedora 28 distribution. 
It is fairly common that functions from <dlfcn.h> are called from DSOs 
which are not linked with -ldl.  The net result is that the references 
to dlsym etc. are not properly versioned.  <pthread.h> and <math.h> are 
also affected.

In the past, we have seen actual bugs related to missing symbol versions 
for functions from librt.

In short, I think this affects all secondary libraries besides 
libc.so.6.  This means that bumping symbol versions for those libraries 
is not an effective way to maintain backwards compatibility.  This is 
something to keep in mind for future changes.  It is also a mild 
argument in favor of moving symbols into libc.so.6, I think.

(Technically, those DSOs are of course incorrectly linked and not 
ABI-compliant, but that doesn't help users who are stuck with them.)

Thanks,
Florian

Re: Symbol versioning for secondary libraries is not effective

[Joseph Myers]

On Fri, 26 Jan 2018, Florian Weimer wrote:

> in mind for future changes.  It is also a mild argument in favor of moving
> symbols into libc.so.6, I think.

Suppose you make the libc.so linker script reference some or all of the 
other libraries inside AS_NEEDED.  Do that result in them being 
automatically linked into shared libraries that use symbols from them, or 
does it only work for executables?

Referencing libraries inside AS_NEEDED is arguably friendlier to users 
anyway - e.g. those not familiar with Unix conventions may not expect to 
need to use -lm.  And POSIX has no notion of a separate -ldl (or -lcrypt) 
being needed to get some standard interfaces.  (There are other ways in 
which an implementation of the POSIX c99 utility is not a completely 
trivial wrapper round "gcc", e.g. the POSIX rules about -D and -U option 
ordering, but there's no need for the library to make it more complicated 
than necessary.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Symbol versioning for secondary libraries is not effective

[Florian Weimer]

On 01/26/2018 01:46 PM, Joseph Myers wrote:
> On Fri, 26 Jan 2018, Florian Weimer wrote:
> 
>> in mind for future changes.  It is also a mild argument in favor of moving
>> symbols into libc.so.6, I think.
> 
> Suppose you make the libc.so linker script reference some or all of the
> other libraries inside AS_NEEDED.  Do that result in them being
> automatically linked into shared libraries that use symbols from them, or
> does it only work for executables?

This will not work for libpthread because some libraries really prefer 
to link against the libc.so.6 definitions, at least for the time being, 
where the libc and libpthread implementations offer different trade-offs.

For libm and libld, this approach appears to work.  The AS_NEEDED 
directive is even overriden by an explicit -lm or -ldl on the command, 
which is good.  It looks like this is something to consider for the next 
release.

> Referencing libraries inside AS_NEEDED is arguably friendlier to users
> anyway - e.g. those not familiar with Unix conventions may not expect to
> need to use -lm.

Yes, a missing -lm seems to be a common obstacle.

Thanks,
Florian

Re: Symbol versioning for secondary libraries is not effective

[Carlos O'Donell]

On 01/29/2018 12:58 AM, Florian Weimer wrote:
> On 01/26/2018 01:46 PM, Joseph Myers wrote:
>> On Fri, 26 Jan 2018, Florian Weimer wrote:
>>
>>> in mind for future changes.  It is also a mild argument in favor of moving
>>> symbols into libc.so.6, I think.
>>
>> Suppose you make the libc.so linker script reference some or all of the
>> other libraries inside AS_NEEDED.  Do that result in them being
>> automatically linked into shared libraries that use symbols from them, or
>> does it only work for executables?
> 
> This will not work for libpthread because some libraries really prefer to link against the libc.so.6 definitions, at least for the time being, where the libc and libpthread implementations offer different trade-offs.
> 
> For libm and libld, this approach appears to work.  The AS_NEEDED directive is even overriden by an explicit -lm or -ldl on the command, which is good.  It looks like this is something to consider for the next release.
> 
>> Referencing libraries inside AS_NEEDED is arguably friendlier to users
>> anyway - e.g. those not familiar with Unix conventions may not expect to
>> need to use -lm.
> 
> Yes, a missing -lm seems to be a common obstacle.

I think an AS_NEEDED for -lm and -ldl would be a step in the right direction.

The only complaint might be that the accidental use of such a symbol will pull
in the new library instead of generating an error, but it's hard to argue this
case. You can always later remove the reference and recompile the program.

-- 
Cheers,
Carlos.