This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Symbol versioning for secondary libraries is not effective


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]