Re: Compatibility .so linker scripts for merged libraries

[Yann Droneaud <ydroneaud@opteya.com>]

Hi,

Le 17/11/2021 à 11:31, Florian Weimer a écrit :
> * Yann Droneaud:
>
>> Was it considered dangerous to introduce "compatibility" .so link
>> scripts for the libraries that was merged into libc.so (libpthread,
>> librt, libdl, etc.) ?
>>
>>
>>
>> For example:
>> $ cat librt.so
>> /* GNU ld script
>>     Use the static library */
>> OUTPUT_FORMAT(elf64-x86-64)
>> GROUP ( /lib/x86_64-linux-gnu/librt.a )
>>
>>
>> Because I'm having some bad times fixing issues in a build system that
>> try to locate now missing .so with gcc -print-file-name= then uses the
>> paths to the libraries instead of -l name them.
> Which build system is that?  This seems to be rather uncommon.

It's surely is uncommon, and need to be fixed.

Adding fake .so would have, in my mind, buying some time to upgrade. But 
this is pointless if no other projects are having the same issue.

> Adding non-loadable .so files tends to break other things.

I was afraid you said that, but I expected it :)

With is piece of information, I have enough motivation to request a fix 
on the build system the project I work for is using.

> We have seen some breakage as well due to the merging, but they have
> been clear bugs in the build systems.  Like testing whether linking
> against -lpthread is needed to make pthread_create available, and then
> using that flag (the need for -lpthread) as an indicator whether
> threading is available and pthread_create should be used.  But the
> -print-file-name= stuff is new to me.


Regards.

-- 

Yann Droneaud

OPTEYA