cross-native build of libstdc++ has libtool with postdeps=-lstdc++...
John Z. Bohach
jzb2@aexorsyst.com
Mon Feb 2 08:18:00 GMT 2009
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
More information about the Gcc-help
mailing list