Compatibility .so linker scripts for merged libraries

Compatibility .so linker scripts for merged libraries

[Yann Droneaud]

Hi,


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.

Regards.

-- 
Yann Droneaud
OPTEYA

Re: Compatibility .so linker scripts for merged libraries

[Andreas Schwab]

If at all, a simple symlink would probably be enough.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Compatibility .so linker scripts for merged libraries

[Yann Droneaud]

Hi,


Le 16/11/2021 à 14:47, Andreas Schwab a écrit :
> If at all, a simple symlink would probably be enough.


A symlink to the .a archive, I should try it. Not sure it's any better.

I thought linker script would be more acceptable as it's already in use 
for /usr/lib/libc.so. But here a symlink to libc_nonshared.a would not work.


-- 

Yann Droneaud
OPTEYA

Re: Compatibility .so linker scripts for merged libraries

[Florian Weimer]

* 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.  Adding
non-loadable .so files tends to break other things.

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.

Thanks,
Florian

Re: Compatibility .so linker scripts for merged libraries

[Yann Droneaud]

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