I'm doing a cross-native of build gcc-4.2.2 on --build=i686-pc-linux-gnu using cross-compiler/toolchain built with --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-uclibc and currently building gcc-4.2.2 for --build=i686-pc-linux-gnu --host=i686-pc-linux-uclibc --target=i686-pc-linux-uclibc with ... --enable-shared --enable-languages=c,c++ --with-sysroot=/data/devo/builds/i686-pc-linux-gnu-cross-i686-pc-linux-uclibc/crucis-1/cross-rootfs ... The generated libtool in gcc_native-build/i686-pc-linux-uclibc/libstdc++v3/libtool ends up with ... postdeps="-lstdc++ -lm -lgcc_s -lc -lgcc_s" ... which seems in error, as it creates a circular dependency of SONAME libstdc++.so on NEEDED libstdc++.so and makes for an ugly RPATH: Dynamic section at offset 0xe789c contains 28 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libm.so.0] 0x00000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x00000001 (NEEDED) Shared library: [libc.so.0] 0x00000001 (NEEDED) Shared library: [libintl.so.0] 0x00000001 (NEEDED) Shared library: [libstdc++.so.6] 0x0000000e (SONAME) Library soname: [libstdc++.so.6] 0x0000000f (RPATH) Library rpath: [/data/devo/builds/i686-pc-linux-gnu-cross-i686-pc-linux-uclibc/crucis-1/cross-tools/i686-pc-linux-uclibc/lib] That RPATH is the location of the libstdc++.so.6.0.9 library from the toolchain. My guess is that this isn't correct. Building a native compiler is fine, and this does not happen, and building a cross-compiler is fine, but when using a cross-compiler to build a native gcc to run on --host=--target, this happens. When it works, in the case of native or cross-compiler, the -lstdc++ value is _not_ present. Is this a known issue? Has anyone else seen this? My cross-toolchain build is fine, and I've built a complete set of over 50 packages that work fine, so I am not suspecting my cross-toolchain. All the -dumpspecs and -print-search-dirs are fine, and yes I've taken out the native build host include paths and library search paths via patches and --with-sysroot. I can send my entire set of steps and configure/make/make install sequence if that's helpful, but I'd just like to get confirmation that this should work, and what I'm seeing is unexpected. And maybe somebody has also hit this...? I noted during the build that gcc_native-build/i686-pc-linux-uclibc/libstdc++v3/libtool was built very early during the gcc_native-build/i686-pc-linux-uclibc/libstdc++v3/ build sequence, and had ... postdeps="-lstdc++ -lm -lgcc_s -lc -lgcc_s" ... long before the Makefile in that directory was ever created. Don't know if that makes any difference, what I do know is that the -lstdc++ value is what seems to drag in the libstdc++.so from the toolchain, and appears in error. What I don't know is how -lstdc++ ends in as part of postdeps in libtool. Any ideas? Thanks, John Z. Bohach
