I ran into a kib@ bugzilla comment and a gerald@ question in response in a bugzilla I was looking at that prompted me to test the status of this again.
QUOTES from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285711 [email protected] in a comment: First wrong thing is that the backtrace ended up in gcc' libgcc_s.so.1 at all. FreeBSD ABI assumes that /lib/libgcc_s.so.1 is used. [email protected] in a later one of the comments: I was wondering - if the system libgcc_s.so.1 is complete for all platforms, maybe simply not install GCC's libgcc? END QUOTES The answer is "not complete": Retesting an old example: # cat fp-binding-failure-aarch64.cpp #include <cmath> volatile long double v=NAN; int main() { return std::isnan(v) ? 1 : 0; } # g++15 fp-binding-failure-aarch64.cpp # ./a.out ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 required by /root/c_tests/a.out not found (This does not happen for a C compile/link. /usr/local/lib/gcc15/libstdc++.so.6 is involved in why the above happens. Also I have 2022 Email history showing the same sort of thing with g++11 in use instead with a different simple C++ program. See later for the modern result for that as well.) # ldd -a a.out a.out: libstdc++.so.6 => /usr/local/lib/gcc15/libstdc++.so.6 (0x29cff5400000) libm.so.5 => /lib/libm.so.5 (0x29cffa7e0000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x29cff415d000) libc.so.7 => /lib/libc.so.7 (0x29cff7000000) /usr/local/lib/gcc15/libstdc++.so.6: libm.so.5 => /lib/libm.so.5 (0x29cffa7e0000) libc.so.7 => /lib/libc.so.7 (0x29cff7000000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x29cff415d000) /lib/libm.so.5: libc.so.7 => /lib/libc.so.7 (0x29cff7000000) /lib/libgcc_s.so.1: libc.so.7 => /lib/libc.so.7 (0x29cff7000000) /lib/libc.so.7: libsys.so.7 => /lib/libsys.so.7 (0x29d006fd0000) vs.: # g++15 -Wl,-rpath=/usr/local/lib/gcc15 fp-binding-failure-aarch64.cpp # ./a.out # ldd -a a.out a.out: libstdc++.so.6 => /usr/local/lib/gcc15/libstdc++.so.6 (0x2fd57d000000) libm.so.5 => /lib/libm.so.5 (0x2fd587cb0000) libgcc_s.so.1 => /usr/local/lib/gcc15/libgcc_s.so.1 (0x2fd58f750000) libc.so.7 => /lib/libc.so.7 (0x2fd57de00000) /usr/local/lib/gcc15/libstdc++.so.6: libm.so.5 => /lib/libm.so.5 (0x2fd587cb0000) libc.so.7 => /lib/libc.so.7 (0x2fd57de00000) libgcc_s.so.1 => /usr/local/lib/gcc15/libgcc_s.so.1 (0x2fd58f750000) /lib/libm.so.5: libc.so.7 => /lib/libc.so.7 (0x2fd57de00000) /usr/local/lib/gcc15/libgcc_s.so.1: libc.so.7 => /lib/libc.so.7 (0x2fd57de00000) /lib/libc.so.7: libsys.so.7 => /lib/libsys.so.7 (0x2fd595480000) For an example that is C++ code that would not compile as C code: # cat locale_failure_test.cpp #include <iostream> #include <locale> int main() { try { std::locale l = std::locale("en_US.UTF-8"); } catch(std::exception const &e) { std::cerr << e.what() << std::endl; } catch(...) { std::cerr << "Unknown exception " << std::endl; } } gets: # g++15 locale_failure_test.cpp # ./a.out ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 required by /usr/local/lib/gcc15/libstdc++.so.6 not found Note the two span both an original program and a gcc* .so library: ) version GCC_4.5.0 required by /root/c_tests/a.out not found vs. ) version GCC_4.5.0 required by /usr/local/lib/gcc15/libstdc++.so.6 not found The issue is tied to not covering the requirements of the g++ code generator output. (I do not know if C code generation is fully covered by /lib/libgcc_s.so.1 use for aarch64. It is not for armv7 last I knew.) I'm not claiming "version GCC_4.5.0" is the only issue for /lib/libgcc_s.so.1 being insufficient to always use: it is just an existence proof example. The status has been long standing and may well be fine. I do not know if "FreeBSD ABI assumes that /lib/libgcc_s.so.1 is used" has a status sufficient to lead to updates dealing with the likes of the above. === Mark Millard marklmi at yahoo.com
