For TARGET_ARCH=powerpc64 it looks like FreeBSD's /lib/libgcc_s.so.1 is incompatible with using the pair: /usr/lib/libc++.so.1 and /lib/libcxxrt.so.1 .
Evidence details follow. (Now using projects/clang380-import -r295902 as a context.) src.conf was set up to have things such that the buildworld/buildkernel that this is based on was via : devel/powerpc64-gcc as the (self hosted) cross compiler ( /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ ) and clang 3.8.0 as the "host" compiler. Later below I list the ldd output for compiling the exception_test.cpp example under different compilers with different options that change what ldd shows and how .so's are found/bound. Some are implicitly using. . . ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/gcc49 /usr/local/lib/gcc6 and others are explicitly bound, such as by -Wl,-rpath=<?> . The only combinations that get the unbounded looping internal to exception handling are the ones that mix 3 things together: /usr/lib/libc++.so.1 /lib/libcxxrt.so.1 /lib/libgcc_s.so.1 That is: exception_test.clang++380.powerpc64 and exception_test.powerpc64-gcc.powerpc64 get the unbounded looping and the others work fine. Note that all 3 libraries were built by devel/powerpc64-gcc during buildworld, not by clang 3.8.0 . And exception_test.powerpc64-gcc.powerpc64 does not involve clang 3.8.0 based code at all. Still libc++.so.1 and libcxxrt.so.1 are "foreign" relative to libgcc_s.so.1 and so there being some form of mismatch possible makes some sense. That same /lib/libgcc_s.so.1 works fine with: /usr/local/lib/gcc49/libstdc++.so.6 and /usr/local/lib/gcc6/libstdc++.so.6 Of course a matched libstdc++/libgcc_s pair for a specific g++ compiler also works. The combinations tested are . . . # ldd *powerpc64 exception_test.clang++380.powerpc64: libc++.so.1 => /usr/lib/libc++.so.1 (0x50054000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x5015a000) libm.so.5 => /lib/libm.so.5 (0x50181000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x501be000) libc.so.7 => /lib/libc.so.7 (0x501e4000) exception_test.g++49-implicitgcc49.powerpc64: libstdc++.so.6 => /usr/local/lib/gcc49/libstdc++.so.6 (0x50054000) libm.so.5 => /lib/libm.so.5 (0x501ed000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x5022a000) libc.so.7 => /lib/libc.so.7 (0x50250000) exception_test.g++49.powerpc64: libstdc++.so.6 => /usr/local/lib/gcc49/libstdc++.so.6 (0x50054000) libm.so.5 => /lib/libm.so.5 (0x501ed000) libgcc_s.so.1 => /usr/local/lib/gcc49/libgcc_s.so.1 (0x5022a000) libc.so.7 => /lib/libc.so.7 (0x50253000) exception_test.g++6-implicitgcc49.powerpc64: libstdc++.so.6 => /usr/local/lib/gcc49/libstdc++.so.6 (0x50054000) libm.so.5 => /lib/libm.so.5 (0x501ed000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x5022a000) libc.so.7 => /lib/libc.so.7 (0x50250000) exception_test.g++6.powerpc64: libstdc++.so.6 => /usr/local/lib/gcc6/libstdc++.so.6 (0x50054000) libm.so.5 => /lib/libm.so.5 (0x502a6000) libgcc_s.so.1 => /usr/local/lib/gcc6/libgcc_s.so.1 (0x502e3000) libc.so.7 => /lib/libc.so.7 (0x5030a000) exception_test.powerpc64-gcc.powerpc64: libc++.so.1 => /usr/lib/libc++.so.1 (0x50053000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x50159000) libm.so.5 => /lib/libm.so.5 (0x50180000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x501bd000) libc.so.7 => /lib/libc.so.7 (0x501e3000) NOTE: Why no g++5 test using its /usr/local/lib/gcc5/libstdc++.so.6? Currently devel/powerpc64-gcc and lang/gcc5 are both at 5.3 and that makes them conflict on files if one tries to build both ports. So I have just devel/powerpc64-gcc, the "officially produced" cross compiler port for targeting modernized powerpc64 builds. === Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"