undefined reference to C++ constructs in libppl when linking cc1-dummy.exe

Arnaud Lacombe lacombar@gmail.com
Wed Sep 1 19:25:00 GMT 2010


Hi,

On Wed, Sep 1, 2010 at 12:43 PM, Doug Crawford <dcraw101@yahoo.com> wrote:
> I ran the build again with "Build shared companion libraries" checked, but now
> it complains about not finding GMP version 4.1.3 duing the ppl configure stage.
> After looking through the mail archives I see that others have this problem
> also, but I did not see a definitive solution.  Just for grins I decided to try
> a canadian cross compile from my Ubuntu 10.04 system where build=x86-linux,
> host=mingw and target=powerpc-linux-uclibc.  During the first toolchain build
> iteration where build/host=x86-linux, target=mingw I encountered the same ppl
> configure error as my cygwin host build: "configure: error: Cannot find GMP
> version 4.1.3 or higher."  In one of the previous emails someone mentioned that
> it was related to the version of libstcc++.   On my Ubuntu system my
> /usr/lib/libstdc++ is pointing to libstdc++.so.6.0.13.
>
> config for my build/host=cygwin target=powerpc-linux-uclibc
> $ ct-ng show-config
> powerpc-860-linux-uclibc  [l  ]
>     OS             : linux-2.6.34.1
>     Companion libs : gmp-4.3.2 mpfr-3.0.0 ppl-0.10.2 cloog-ppl-0.15.9
>     binutils       : binutils-2.20.1
>     C compiler     : gcc-4.4.3 (C,C++)
>     C library      : uClibc-0.9.30.2
>     Tools          : gdb-6.8 strace-4.5.19
>
> config for my build/host=x86-linux target=mingw
> i386-unknown-mingw32  [l X]
>     OS             : mingw32
>     Companion libs : gmp-5.0.1 mpfr-3.0.0 ppl-0.10.2 cloog-ppl-0.15.9
>     binutils       : binutils-2.20.1
>     C compiler     : gcc-4.4.3 (C,C++)
>     C library      : mingw
>     Tools          :
>
there is a known issue and a patch for gmp-5.0.1/ppl-0.10.2, I'm not
sure being aware of anything between prior gmp and ppl.

Concerning your original link trouble I'm not sure ld(1) behave the
same on *nix and cygwin. I found an old post concerning a similar
behavior:

http://osdir.com/ml/sysutils.autoconf.general/2004-06/msg00104.html

I confirmed this with a trivial test program;

On cygwin:
% gcc -lz main.c # FAILS: undefined refs to `gzopen'
% gcc main.c -lz # WORKS

both works on *nix.

This might be related to PE/COFF import handling (say some IRC guy on
#cygwin). Anyhow, `-lstdc++' must definitively appear after, as it is
done in 4.5. We are just lucky (and plainly wrong) to hijack LDFLAGS
to specify -lstdc++ before.

The short answer might be "static linking of companion library prior
to gcc 4.5 is not reliable", beside hack like:

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 88c40b6..9881ac4 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1642,8 +1642,8 @@ gcc-cross$(exeext): xgcc$(exeext)
 dummy-checksum.o : dummy-checksum.c

 cc1-dummy$(exeext): $(C_OBJS) dummy-checksum.o $(BACKEND) $(LIBDEPS)
-       $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ $(C_OBJS) dummy-checksum.o \
-         $(BACKEND) $(LIBS) $(BACKENDLIBS)
+       $(CC) $(ALL_CFLAGS) -o $@ $(C_OBJS) dummy-checksum.o \
+         $(BACKEND) $(LIBS) $(BACKENDLIBS) $(LDFLAGS)

 cc1-checksum.c : cc1-dummy$(exeext) build/genchecksum$(build_exeext)
        build/genchecksum$(build_exeext) cc1-dummy$(exeext) > $@
@@ -1651,8 +1651,8 @@ cc1-checksum.c : cc1-dummy$(exeext)
build/genchecksum$(build_exeext)
 cc1-checksum.o : cc1-checksum.c

 cc1$(exeext): $(C_OBJS) cc1-checksum.o $(BACKEND) $(LIBDEPS)
-       $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ $(C_OBJS) cc1-checksum.o \
-         $(BACKEND) $(LIBS) $(BACKENDLIBS)
+       $(CC) $(ALL_CFLAGS) -o $@ $(C_OBJS) cc1-checksum.o \
+         $(BACKEND) $(LIBS) $(BACKENDLIBS) $(LDFLAGS)

which should work.

 - Arnaud

--
For unsubscribe information see http://sourceware.org/lists.html#faq



More information about the crossgcc mailing list