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