* cross-native build of libstdc++ has libtool with postdeps=-lstdc++...
@ 2009-02-02 8:18 John Z. Bohach
0 siblings, 0 replies; only message in thread
From: John Z. Bohach @ 2009-02-02 8:18 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2009-02-02 8:18 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-02 8:18 cross-native build of libstdc++ has libtool with postdeps=-lstdc++ John Z. Bohach
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).