projects/clang380-import for TARGET_ARCH=powerpc64: /lib/libgcc_s.so.1 is incompatible with using the pair: /usr/lib/libc++.so.1 and /lib/libcxxrt.so.1 for C++ exception handling

[Mark Millard]

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