Re: Fine granularity of control over libgcc* search paths

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux