Reminder that, on aarch64 (tier 1), /lib/libgcc_s.so.1 is not an always valid replacement for using /usr/local/lib/gcc*/libgcc_s.so.1

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
kib@FreeBSD.org 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.

gerald@FreeBSD.org 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