Date: Tue, 23 Feb 2016 01:50:31 -0800 From: Mark Millard <markmi@dsl-only.net> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Cc: Roman Divacky <rdivacky@vlakno.cz>, Dimitry Andric <dim@FreeBSD.org> Subject: 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 Message-ID: <5B9137BF-0E86-4C4B-A3FB-18F444A850AC@dsl-only.net>
next in thread | raw e-mail | index | archive | help
For TARGET_ARCH=3Dpowerpc64 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=3D<?> . 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 =3D> /usr/lib/libc++.so.1 (0x50054000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x5015a000) libm.so.5 =3D> /lib/libm.so.5 (0x50181000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x501be000) libc.so.7 =3D> /lib/libc.so.7 (0x501e4000) exception_test.g++49-implicitgcc49.powerpc64: libstdc++.so.6 =3D> /usr/local/lib/gcc49/libstdc++.so.6 = (0x50054000) libm.so.5 =3D> /lib/libm.so.5 (0x501ed000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x5022a000) libc.so.7 =3D> /lib/libc.so.7 (0x50250000) exception_test.g++49.powerpc64: libstdc++.so.6 =3D> /usr/local/lib/gcc49/libstdc++.so.6 = (0x50054000) libm.so.5 =3D> /lib/libm.so.5 (0x501ed000) libgcc_s.so.1 =3D> /usr/local/lib/gcc49/libgcc_s.so.1 = (0x5022a000) libc.so.7 =3D> /lib/libc.so.7 (0x50253000) exception_test.g++6-implicitgcc49.powerpc64: libstdc++.so.6 =3D> /usr/local/lib/gcc49/libstdc++.so.6 = (0x50054000) libm.so.5 =3D> /lib/libm.so.5 (0x501ed000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x5022a000) libc.so.7 =3D> /lib/libc.so.7 (0x50250000) exception_test.g++6.powerpc64: libstdc++.so.6 =3D> /usr/local/lib/gcc6/libstdc++.so.6 = (0x50054000) libm.so.5 =3D> /lib/libm.so.5 (0x502a6000) libgcc_s.so.1 =3D> /usr/local/lib/gcc6/libgcc_s.so.1 = (0x502e3000) libc.so.7 =3D> /lib/libc.so.7 (0x5030a000) exception_test.powerpc64-gcc.powerpc64: libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x50053000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x50159000) libm.so.5 =3D> /lib/libm.so.5 (0x50180000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x501bd000) libc.so.7 =3D> /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. =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5B9137BF-0E86-4C4B-A3FB-18F444A850AC>