Fine granularity of control over libgcc* search paths

Fine granularity of control over libgcc* search paths

[R jd]

[-- Attachment #1: Type: text/plain, Size: 2529 bytes --]

I have tried for some hours to figure out how to get full control over the
paths that are implicitly searched for *libgcc.a*.

As an example, here is the command that is passed to *collect2*:

/usr/lib/gcc/x86_64-linux-gnu/11/collect2 -plugin
/usr/lib/gcc/x86_64-linux-gnu/11/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccwIgXt9.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
--build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed
-dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro -o main
/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/Scrt1.o
/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/11/crtbeginS.o
-L/usr/lib/gcc/x86_64-linux-gnu/11
-L/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib -L/lib/x86_64-linux-gnu
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-linux-gnu/11/../../.. --verbose /tmp/ccR9vB4k.o -lgcc
--push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state
--as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-linux-gnu/11/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/crtn.o

This boils down to something like:

[LINK_SPEC] [STARTFILE_SPEC] [The Evasive Library Paths] --verbose
/tmp/ccR9vB4k.o [REAL_LIBGCC_SPEC] [LIB_SPEC] .....

Where, [The Evasive Library Paths] = -L/usr/lib/gcc/x86_64-linux-gnu/11
-L/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib -L/lib/x86_64-linux-gnu
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-linux-gnu/11/../../..

It is [The Evasive Library Paths] that I am trying to get fine control
over. It seems that these are just automatically inserted because we are
linking with -lgcc which makes total sense - but I need to have full
control over it and may want to change it. The rest of the command line for
*collect2* is understandable and modifiable since I can match it up with
the relevant SPEC file. Only these evasive library paths are causing me a
lot of wasted hours.

I was looking at *LINK_COMMAND_SPEC* (
https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gccint/Driver.html) as a potential
work around, but I thought that, since it is already late, I would just ask
on here.

Regards,

Re: Fine granularity of control over libgcc* search paths

[Stefan Ring]

On Wed, Nov 8, 2023 at 1:21 AM R jd via Gcc-help <gcc-help@gcc.gnu.org> wrote:
>
> Where, [The Evasive Library Paths] = -L/usr/lib/gcc/x86_64-linux-gnu/11
> -L/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu
> -L/usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib -L/lib/x86_64-linux-gnu
> -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
> -L/usr/lib/gcc/x86_64-linux-gnu/11/../../..
>
> It is [The Evasive Library Paths] that I am trying to get fine control
> over. It seems that these are just automatically inserted because we are
> linking with -lgcc which makes total sense - but I need to have full
> control over it and may want to change it. The rest of the command line for
> *collect2* is understandable and modifiable since I can match it up with
> the relevant SPEC file. Only these evasive library paths are causing me a
> lot of wasted hours.
>
> I was looking at *LINK_COMMAND_SPEC* (
> https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gccint/Driver.html) as a potential
> work around, but I thought that, since it is already late, I would just ask
> on here.

Are you aware of --sysroot? This is probably what you actually want.

Re: Fine granularity of control over libgcc* search paths

[Kai Ruottu]

[-- Attachment #1: Type: text/plain, Size: 2256 bytes --]

R jd via Gcc-help kirjoitti 8.11.2023 klo 2.20:
> I have tried for some hours to figure out how to get full control over the
> paths that are implicitly searched for *libgcc.a*.

This reply isn't directly related to your problem but related to finding 
the right shared libgcc's in cross-compilers.

I mean the peculiarity seen in the following :

[kairuottu@fedora test]$ powerpc64-centos-linux7.9-gcc-13 -o 
hello_world_powerc64 hello_world.c [kairuottu@fedora test]$ 
powerpc64-centos-linux7.9-gcc-14 -o hello_world_powerc64 hello_world.c 
/opt/cross64/bin/../lib/gcc/powerpc64-centos-linux7.9/14.0.0/../../../../powerpc64-centos-linux7.9/bin/ld: 
cannot find -lgcc_s collect2: error: ld returned 1 exit status 
[kairuottu@fedora test]$ cd /opt/cross/lib/gcc/powerpc64-centos-linux7.9 
[kairuottu@fedora powerpc64-centos-linux7.9]$ ls -l -t yhteensä 56 
drwxr-xr-x. 7 root root 4096 12.11. 19:52 14.0.0 drwxr-xr-x. 2 root root 
4096 12.11. 19:51 lib drwxr-xr-x. 2 root root 4096 12.11. 19:51 lib64 
drwxr-xr-x. 7 root root 4096 1. 8. 23:53 13.2.0 drwxr-xr-x. 7 root root 
4096 10. 7. 15:47 10.5.0 drwxr-xr-x. 7 root root 4096 2. 6. 19:11 11.4.0 
drwxr-xr-x. 7 root root 4096 12. 5. 2023 12.3.0 drwxr-xr-x. 7 root root 
4096 11. 5. 2023 9.5.0 drwxr-xr-x. 7 root root 4096 11. 5. 2023 8.5.0 
drwxr-xr-x. 7 root root 4096 11. 5. 2023 7.5.0 drwxr-xr-x. 7 root root 
4096 11. 5. 2023 6.5.0 drwxr-xr-x. 8 root root 4096 11. 5. 2023 4.9.4 
drwxr-xr-x. 8 root root 4096 11. 5. 2023 5.5.0 drwxr-xr-x. 8 root root 
4096 10. 5. 2023 4.8.5 [kairuottu@fedora powerpc64-centos-linux7.9]$ ls 
lib* lib: libgcc_s.so libgcc_s.so.1 lib64: libgcc_s.so libgcc_s.so.1

The peculiarity is that the 'libgcc_s.so*' stuff isn't installed into 
the GCC-version dependent directory as expected when using the 
'--enable-version-specific-runtime-libs' in the GCC configure command. 
But installed in separare 'lib*' directories where they will not be 
found. After the gcc-13.2.0 and earlier GCC builds for the same target 
this peculiarity was fixed via manually moving the 'libgcc_s' stuff 
where it should be after running 'make install'.

I don't remember when this issue started, maybe it was in gcc-9.5.0 or 
gcc-10.5.0. Is this a bug or is there some sanity in this thing?

Re: Fine granularity of control over libgcc* search paths

[Kai Ruottu]

Kai Ruottu kirjoitti 12.11.2023 klo 21.29:
> R jd via Gcc-help kirjoitti 8.11.2023 klo 2.20:
>> I have tried for some hours to figure out how to get full control 
>> over the
>> paths that are implicitly searched for *libgcc.a*.
>
> This reply isn't directly related to your problem but related to 
> finding the right shared libgcc's in cross-compilers.
>
> I mean the peculiarity seen in the following :
>
Let's try again this copy & paste :

[kairuottu@fedora test]$ powerpc64-centos-linux7.9-gcc-13 -o 
hello_world_powerc64 hello_world.c
[kairuottu@fedora test]$ powerpc64-centos-linux7.9-gcc-14 -o 
hello_world_powerc64 hello_world.c
/opt/cross64/bin/../lib/gcc/powerpc64-centos-linux7.9/14.0.0/../../../../powerpc64-centos-linux7.9/bin/ld: 
cannot find -lgcc_s
collect2: error: ld returned 1 exit status
[kairuottu@fedora test]$ cd /opt/cross/lib/gcc/powerpc64-centos-linux7.9
[kairuottu@fedora powerpc64-centos-linux7.9]$ ls -l -t
yhteensä 56
drwxr-xr-x. 7 root root 4096 12.11. 19:52 14.0.0
drwxr-xr-x. 2 root root 4096 12.11. 19:51 lib
drwxr-xr-x. 2 root root 4096 12.11. 19:51 lib64
drwxr-xr-x. 7 root root 4096  1. 8. 23:53 13.2.0
drwxr-xr-x. 7 root root 4096 10. 7. 15:47 10.5.0
drwxr-xr-x. 7 root root 4096  2. 6. 19:11 11.4.0
drwxr-xr-x. 7 root root 4096 12. 5.  2023 12.3.0
drwxr-xr-x. 7 root root 4096 11. 5.  2023 9.5.0
drwxr-xr-x. 7 root root 4096 11. 5.  2023 8.5.0
drwxr-xr-x. 7 root root 4096 11. 5.  2023 7.5.0
drwxr-xr-x. 7 root root 4096 11. 5.  2023 6.5.0
drwxr-xr-x. 8 root root 4096 11. 5.  2023 4.9.4
drwxr-xr-x. 8 root root 4096 11. 5.  2023 5.5.0
drwxr-xr-x. 8 root root 4096 10. 5.  2023 4.8.5
[kairuottu@fedora powerpc64-centos-linux7.9]$ ls lib*
lib:
libgcc_s.so  libgcc_s.so.1

lib64:
libgcc_s.so  libgcc_s.so.1

Re: Fine granularity of control over libgcc* search paths

[Jonathan Wakely]

On Sun, 12 Nov 2023 at 19:30, Kai Ruottu <kai.ruottu@wippies.com> wrote:
>
> R jd via Gcc-help kirjoitti 8.11.2023 klo 2.20:
> > I have tried for some hours to figure out how to get full control over the
> > paths that are implicitly searched for *libgcc.a*.
>
> This reply isn't directly related to your problem but related to finding
> the right shared libgcc's in cross-compilers.
>
> I mean the peculiarity seen in the following :
>
> [kairuottu@fedora test]$ powerpc64-centos-linux7.9-gcc-13 -o
> hello_world_powerc64 hello_world.c [kairuottu@fedora test]$
> powerpc64-centos-linux7.9-gcc-14 -o hello_world_powerc64 hello_world.c
> /opt/cross64/bin/../lib/gcc/powerpc64-centos-linux7.9/14.0.0/../../../../powerpc64-centos-linux7.9/bin/ld:
> cannot find -lgcc_s collect2: error: ld returned 1 exit status
> [kairuottu@fedora test]$ cd /opt/cross/lib/gcc/powerpc64-centos-linux7.9
> [kairuottu@fedora powerpc64-centos-linux7.9]$ ls -l -t yhteensä 56
> drwxr-xr-x. 7 root root 4096 12.11. 19:52 14.0.0 drwxr-xr-x. 2 root root
> 4096 12.11. 19:51 lib drwxr-xr-x. 2 root root 4096 12.11. 19:51 lib64
> drwxr-xr-x. 7 root root 4096 1. 8. 23:53 13.2.0 drwxr-xr-x. 7 root root
> 4096 10. 7. 15:47 10.5.0 drwxr-xr-x. 7 root root 4096 2. 6. 19:11 11.4.0
> drwxr-xr-x. 7 root root 4096 12. 5. 2023 12.3.0 drwxr-xr-x. 7 root root
> 4096 11. 5. 2023 9.5.0 drwxr-xr-x. 7 root root 4096 11. 5. 2023 8.5.0
> drwxr-xr-x. 7 root root 4096 11. 5. 2023 7.5.0 drwxr-xr-x. 7 root root
> 4096 11. 5. 2023 6.5.0 drwxr-xr-x. 8 root root 4096 11. 5. 2023 4.9.4
> drwxr-xr-x. 8 root root 4096 11. 5. 2023 5.5.0 drwxr-xr-x. 8 root root
> 4096 10. 5. 2023 4.8.5 [kairuottu@fedora powerpc64-centos-linux7.9]$ ls
> lib* lib: libgcc_s.so libgcc_s.so.1 lib64: libgcc_s.so libgcc_s.so.1
>
> The peculiarity is that the 'libgcc_s.so*' stuff isn't installed into
> the GCC-version dependent directory as expected when using the
> '--enable-version-specific-runtime-libs' in the GCC configure command.
> But installed in separare 'lib*' directories where they will not be
> found. After the gcc-13.2.0 and earlier GCC builds for the same target
> this peculiarity was fixed via manually moving the 'libgcc_s' stuff
> where it should be after running 'make install'.
>
> I don't remember when this issue started, maybe it was in gcc-9.5.0 or
> gcc-10.5.0. Is this a bug or is there some sanity in this thing?

--enable-version-specific-runtime-libs has been broken for years:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32415

Re: Fine granularity of control over libgcc* search paths

[R jd]

[-- Attachment #1: Type: text/plain, Size: 3586 bytes --]

I should have probably mentioned that my issue is to do with "multilib".
The example that I posted in the original post was on my native machine. In
fact, I am building compiler toolchains for AmigaNG. For this, we actually
have 3 different C runtime libraries. We build this by using "multilib".
The default is newlib, followed by two multilibs - if you like - named
clib2 and clib4.

What happens is that I notice during the linking of a program, whichever
non-default lib is being used (clib2/clib4) had these implicitly added -L
options, but it is always followed by the "default" lib (newlib).
Semantically, this seems a little naughty. When debugging through the GCC.C
file, I see that there are functions that seem to append the "default"
paths _after_ the clib[24] lib paths. This is fine, so long as they are
after, but just feels dirty.

Thanks.

On Sun, 12 Nov 2023 at 21:37, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:

> On Sun, 12 Nov 2023 at 19:30, Kai Ruottu <kai.ruottu@wippies.com> wrote:
> >
> > R jd via Gcc-help kirjoitti 8.11.2023 klo 2.20:
> > > I have tried for some hours to figure out how to get full control over
> the
> > > paths that are implicitly searched for *libgcc.a*.
> >
> > This reply isn't directly related to your problem but related to finding
> > the right shared libgcc's in cross-compilers.
> >
> > I mean the peculiarity seen in the following :
> >
> > [kairuottu@fedora test]$ powerpc64-centos-linux7.9-gcc-13 -o
> > hello_world_powerc64 hello_world.c [kairuottu@fedora test]$
> > powerpc64-centos-linux7.9-gcc-14 -o hello_world_powerc64 hello_world.c
> >
> /opt/cross64/bin/../lib/gcc/powerpc64-centos-linux7.9/14.0.0/../../../../powerpc64-centos-linux7.9/bin/ld:
> > cannot find -lgcc_s collect2: error: ld returned 1 exit status
> > [kairuottu@fedora test]$ cd /opt/cross/lib/gcc/powerpc64-centos-linux7.9
> > [kairuottu@fedora powerpc64-centos-linux7.9]$ ls -l -t yhteensä 56
> > drwxr-xr-x. 7 root root 4096 12.11. 19:52 14.0.0 drwxr-xr-x. 2 root root
> > 4096 12.11. 19:51 lib drwxr-xr-x. 2 root root 4096 12.11. 19:51 lib64
> > drwxr-xr-x. 7 root root 4096 1. 8. 23:53 13.2.0 drwxr-xr-x. 7 root root
> > 4096 10. 7. 15:47 10.5.0 drwxr-xr-x. 7 root root 4096 2. 6. 19:11 11.4.0
> > drwxr-xr-x. 7 root root 4096 12. 5. 2023 12.3.0 drwxr-xr-x. 7 root root
> > 4096 11. 5. 2023 9.5.0 drwxr-xr-x. 7 root root 4096 11. 5. 2023 8.5.0
> > drwxr-xr-x. 7 root root 4096 11. 5. 2023 7.5.0 drwxr-xr-x. 7 root root
> > 4096 11. 5. 2023 6.5.0 drwxr-xr-x. 8 root root 4096 11. 5. 2023 4.9.4
> > drwxr-xr-x. 8 root root 4096 11. 5. 2023 5.5.0 drwxr-xr-x. 8 root root
> > 4096 10. 5. 2023 4.8.5 [kairuottu@fedora powerpc64-centos-linux7.9]$ ls
> > lib* lib: libgcc_s.so libgcc_s.so.1 lib64: libgcc_s.so libgcc_s.so.1
> >
> > The peculiarity is that the 'libgcc_s.so*' stuff isn't installed into
> > the GCC-version dependent directory as expected when using the
> > '--enable-version-specific-runtime-libs' in the GCC configure command.
> > But installed in separare 'lib*' directories where they will not be
> > found. After the gcc-13.2.0 and earlier GCC builds for the same target
> > this peculiarity was fixed via manually moving the 'libgcc_s' stuff
> > where it should be after running 'make install'.
> >
> > I don't remember when this issue started, maybe it was in gcc-9.5.0 or
> > gcc-10.5.0. Is this a bug or is there some sanity in this thing?
>
> --enable-version-specific-runtime-libs has been broken for years:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32415
>