Re: Fine granularity of control over libgcc* search paths

[R jd <3246251196ryan@gmail.com>]

[-- 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
>