[Bug libstdc++/35942] Self Reference In Dynamic Linked Library builds for building Cross-Compiler

[jzb2 at aexorsyst dot com]

------- Comment #10 from jzb2 at aexorsyst dot com  2009-02-02 09:31 -------
I can confirm this is a real problem.  I have hit this exact same bug on
gcc-4.2.2.  However, one difference in my setup is that I _do_ have
libstdc++.so available as part of my cross toolchain, with the result the
libtool happily generates code that ends up linking the cross-toolchain's
libstdc++.so into the cross-native (not Canandian) libstdc++.so just being
built, and adds an ugly RPATH to it as well.  I've sent the following to
gcc-help mailing list, before I found this current bug on bugzilla:

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]

Note that if instead of libstdc++.so I only have libstdc++.a in the toolchain,
then I get a bunch of duplicate symbols and the link fails (I suppose that's
expected at this point).

I'm pretty sure this used to work in earlier versions, but its broken in 4.2.2
and has nothing to do with (in 4.2.2) the --build option, as I do specify it. 
Here's my full cross-native configure command:

cd $(OBJDIR)/gcc_native-build ; \
          CXXFLAGS=-fpermissive \
            CC=$(ARCH)-$(CUSTOMER)-$(PLATFORM)-gcc \
            $(PKGDIR)/configure --prefix=/usr \
                                --libexecdir=/usr/lib \
                                --enable-shared \
                                --enable-threads=posix \
                                --enable-__cxa_atexit \
                                --enable-clocale=uclibc \
                                --with-cpu=pentium4 \
                                --with-local-prefix=$(TGTROOT)/usr \
                                --with-sysroot=$(TGTROOT) \
                                --enable-languages=c,c++ \
                                --disable-libstdcxx-pch \
                                --build=$(BUILDHOST) \
                                --host=$(ARCH)-$(CUSTOMER)-$(PLATFORM) \
                                --target=$(ARCH)-$(CUSTOMER)-$(PLATFORM)

And here's how the cross-compiler was built (prior to building gcc_native):

cd $(OBJDIR)/gcc_p2-build ; \
          CXXFLAGS=-fpermissive $(PKGDIR)/configure \
                   --prefix=$(PREFIX) \
                   --disable-werror \
                   --disable-multilib \
                   --enable-clocale=uclibc \
                   --enable-shared \
                   --libexecdir=$(PREFIX)/lib \
                   --with-headers=$(TGTROOT)/usr/include \
                   --with-sysroot=$(TGTROOT) \
                   --enable-threads=posix \
                   --enable-__cxa_atexit \
                   --with-cpu=pentium4 \
                   --enable-languages=c,c++ \
                   --target=$(ARCH)-$(CUSTOMER)-$(PLATFORM)

Note that -fpermissive flag is to overcome uClibc's gettext issues, and was
suggested by the gcc itself as it tried to build.  It works with, not without,
but probably has nothing to do this generated libtool issue.  The uclibc locale
was supplied via patches.

I am a programmer, but not a autoconf/automake/libtool expert, so if someone
could just please point out where that postdeps gets instantiated, and how it
has come to include -lstdc++, I'd be happy to run some tests.

Is it possible that this may have to do with the version(s) of the
autoconf/automake tools?  Is that where perhaps the postdeps gets its value? 
I'm just guessing, as I've grepped the whole gcc source tree, and couldn't find
anything useful.  That would also explain the unexpected difference in
behavior.

I'm running autoconf-2.61 and automake-1.10.1 and libtool-1.5.24 on the
$(BUILDHOST).


-- 

jzb2 at aexorsyst dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jzb2 at aexorsyst dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35942