[This was discovered while looking into another issue not
known at the time to be associated with fluxengine.]
sysutils/fluxengine on the FreeBSD ports bulk-build servers for
targetting aarch64 currently uses gcc10 to satisfy:
USES= compiler:gcc-c++11-lib . . .
but it fails to build via:
ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 required by . . .
errors. Basically, the wrong libgcc_s.so.1 is in use.
It turns out a form of this happens even for building fairly trivial
code with gcc10 or gcc11 (or . . .? Unknown range) when the matching:
-Wl,-rpath=/usr/local/lib/gcc*
is not supplied. (I happen to have gcc11 installed, thus some
details of the below example.)
# g++11 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/gcc11/libstdc++.so.6 not found
# ldd a.out
a.out:
libstdc++.so.6 => /usr/local/lib/gcc11/libstdc++.so.6 (0x82400000)
libm.so.5 => /lib/libm.so.5 (0x81411000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x82b01000)
libc.so.7 => /lib/libc.so.7 (0x8376e000)
compared to:
# g++11 -Wl,-rpath=/usr/local/lib/gcc11 locale_failure_test.cpp
# ./a.out
# ldd a.out
a.out:
libstdc++.so.6 => /usr/local/lib/gcc11/libstdc++.so.6 (0x83400000)
libm.so.5 => /lib/libm.so.5 (0x81a6f000)
libgcc_s.so.1 => /usr/local/lib/gcc11/libgcc_s.so.1 (0x8265c000)
libc.so.7 => /lib/libc.so.7 (0x83fbe000)
where the source code compiled is:
#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;
}
}
There may be other ports with the issue.
===
Mark Millard
marklmi at yahoo.com
