* Compatibility .so linker scripts for merged libraries
@ 2021-11-16 13:27 Yann Droneaud
2021-11-16 13:47 ` Andreas Schwab
2021-11-17 10:31 ` Florian Weimer
0 siblings, 2 replies; 5+ messages in thread
From: Yann Droneaud @ 2021-11-16 13:27 UTC (permalink / raw)
To: libc-alpha
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Compatibility .so linker scripts for merged libraries
2021-11-16 13:27 Compatibility .so linker scripts for merged libraries Yann Droneaud
@ 2021-11-16 13:47 ` Andreas Schwab
2021-11-16 13:54 ` Yann Droneaud
2021-11-17 10:31 ` Florian Weimer
1 sibling, 1 reply; 5+ messages in thread
From: Andreas Schwab @ 2021-11-16 13:47 UTC (permalink / raw)
To: Yann Droneaud; +Cc: libc-alpha
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."
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Compatibility .so linker scripts for merged libraries
2021-11-16 13:47 ` Andreas Schwab
@ 2021-11-16 13:54 ` Yann Droneaud
0 siblings, 0 replies; 5+ messages in thread
From: Yann Droneaud @ 2021-11-16 13:54 UTC (permalink / raw)
To: libc-alpha
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Compatibility .so linker scripts for merged libraries
2021-11-16 13:27 Compatibility .so linker scripts for merged libraries Yann Droneaud
2021-11-16 13:47 ` Andreas Schwab
@ 2021-11-17 10:31 ` Florian Weimer
2021-11-17 21:32 ` Yann Droneaud
1 sibling, 1 reply; 5+ messages in thread
From: Florian Weimer @ 2021-11-17 10:31 UTC (permalink / raw)
To: Yann Droneaud; +Cc: libc-alpha
* 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Compatibility .so linker scripts for merged libraries
2021-11-17 10:31 ` Florian Weimer
@ 2021-11-17 21:32 ` Yann Droneaud
0 siblings, 0 replies; 5+ messages in thread
From: Yann Droneaud @ 2021-11-17 21:32 UTC (permalink / raw)
To: Florian Weimer; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-11-17 21:33 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-16 13:27 Compatibility .so linker scripts for merged libraries Yann Droneaud
2021-11-16 13:47 ` Andreas Schwab
2021-11-16 13:54 ` Yann Droneaud
2021-11-17 10:31 ` Florian Weimer
2021-11-17 21:32 ` Yann Droneaud
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).