Re: libstdc++.so depends on libstdc++.so

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



tp@xxxxxxx wrote:
Hi,

I'm cross-compiling gcc (with c++ enabled) to run on an arm target.
Overall it works well, except:

$ arm-unknown-linux-uclibc-readelf -d libstdc++.so.6.0.8
...
 0x00000001 (NEEDED)                     Shared library: [libstdc++.so.6]
 0x0000000e (SONAME)                     Library soname: [libstdc++.so.6]
 0x0000000f (RPATH)                      Library rpath: [/home/.../arm-unknown-linux-uclibc/lib]

The resulting libstdc++ depends on libstdc++ and has an rpath into the
cross-tools directory. I've had the same with a glibc-based toolchain
and with gcc 3.4, 4.1 and 4.2.

That doesn't happen to me: I get

$ ./bin/arm-linux-gnueabi-readelf -d ./arm-linux-gnueabi/lib/libstdc++.so.6.0.10
Dynamic section at offset 0xc5ef4 contains 29 entries:
 Tag        Type                         Name/Value
0x00000001 (NEEDED)                     Shared library: [libm.so.6]
0x00000001 (NEEDED)                     Shared library: [libc.so.6]
0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
0x0000000e (SONAME)                     Library soname: [libstdc++.so.6]

I'd like to know exactly how this was configured and built.

Comments in the configure scripts and Makefiles indicate that
libstdc++ is not to be linked with target-g++, because that includes
-lstdc++. But it's exactly doing that. I haven't found a way to make
it do the right thing, except dirty sed'ding various libtool and
configure scripts.
Another annoyance appears when libiconv is installed in the target
sysroot. If gcc's configure detects iconv.h there, the
target-sysroot/include path ends up in CPPFLAGS in gcc/Makefile, which
in turn is used to build gcc/build/gen* - which of course fails
(mixing glibc host headers and uclibc target headers). None of
--without-iconv-prefix, --with-iconv-prefix=/target-sysroot or
--with-iconv-prefix=/usr helped. Sed'ding gcc/Makefile (remove
CPPFLAGS from BUILD_CFLAGS) helps.

This doesn't happen to me either.  I have iconv.h in my sysroot too.

Here's what I did:

 $ /home/aph/gcc/trunk/configure --prefix=/local/x-arm-gcc/install --with-build-sysroot=/local/x-arm-gcc/rootfs-f8 --disable-libssp --disable-libgomp --disable-libmudflap --enable-libgcj --disable-bootstrap --disable-multilib --disable-static --disable-sjlj-exceptions --target=arm-linux-gnueabi --enable-languages=c,c++,java

Andrew.

[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux