libstdc++.so depends on libstdc++.so

libstdc++.so depends on libstdc++.so

[tp]

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.

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.

Thanks in advance for explanations on how this should really work,

Tobias

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

[Andrew Haley]

tp@fonz.de 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.