Date: Thu, 7 Apr 2022 17:46:36 -0700 From: Mark Millard <marklmi@yahoo.com> To: freebsd-ports@freebsd.org, "crees@freebsd.org" <crees@FreeBSD.org> Subject: sysutils/fluxengine apparently needs to use an appropriate -Wl,-rpath=/usr/local/lib/gcc* Message-ID: <6DC9C9DA-A345-426A-A1BB-F0104E6E4F13@yahoo.com> References: <6DC9C9DA-A345-426A-A1BB-F0104E6E4F13.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[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=3D 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=3D/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 =3D> /usr/local/lib/gcc11/libstdc++.so.6 = (0x82400000) libm.so.5 =3D> /lib/libm.so.5 (0x81411000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x82b01000) libc.so.7 =3D> /lib/libc.so.7 (0x8376e000) compared to: # g++11 -Wl,-rpath=3D/usr/local/lib/gcc11 locale_failure_test.cpp # ./a.out # ldd a.out a.out: libstdc++.so.6 =3D> /usr/local/lib/gcc11/libstdc++.so.6 = (0x83400000) libm.so.5 =3D> /lib/libm.so.5 (0x81a6f000) libgcc_s.so.1 =3D> /usr/local/lib/gcc11/libgcc_s.so.1 = (0x8265c000) libc.so.7 =3D> /lib/libc.so.7 (0x83fbe000) where the source code compiled is: #include <iostream> #include <locale> int main() { try { std::locale l =3D 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. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6DC9C9DA-A345-426A-A1BB-F0104E6E4F13>