Build error on Debian Lenny i386

[vcaron]

On a fresh SVN checkout (revision 42):

$ ./build.sh all
./build.sh: Making target all on Linux-i386
make[1]: Entering directory `/home/zerodeux/src/openmoko/runningbear/trunk/System/Sources/libc/src'
make[2]: Entering directory `/home/zerodeux/src/openmoko/runningbear/trunk/System/Sources/libc/src/dl'
libtool --mode=compile cc -nostdinc -I ../../include -I ../../include/dl  -W -Wall -g -ansi -ffreestanding -c dlfcn.c
mkdir .libs
 cc -nostdinc -I ../../include -I ../../include/dl -W -Wall -g -ansi -ffreestanding -c dlfcn.c  -fPIC -o .libs/dlfcn.o
dlfcn.c:80:3: warning: #warning Assuming big-endian
dlfcn.c:355: warning: unused parameter ‘mode’
 cc -nostdinc -I ../../include -I ../../include/dl -W -Wall -g -ansi -ffreestanding -c dlfcn.c -o dlfcn.o >/dev/null 2>&1
libtool --mode=link cc -o libdl.la dlfcn.lo -rpath /usr/local/lib
cc -shared  .libs/dlfcn.o   -Wl,-soname -Wl,libdl.so.0 -o .libs/libdl.so.0.0.0
/usr/bin/ld: errno: TLS definition in /lib/libc.so.6 section .tbss mismatches non-TLS reference in .libs/dlfcn.o
/lib/libc.so.6: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [libdl.la] Error 1
make[2]: Leaving directory `/home/zerodeux/src/openmoko/runningbear/trunk/System/Sources/libc/src/dl'
make[1]: *** [subdirs] Error 2
make[1]: Leaving directory `/home/zerodeux/src/openmoko/runningbear/trunk/System/Sources/libc/src'
make: *** [subdirs] Error 2

[vcaron]

Ops, forgot some essentials...

GNU Make 3.81
gcc (Debian 4.3.1-9) 4.3.1
GNU ld (GNU Binutils for Debian) 2.18.0.20080103
libc6 2.7

[ppronchery]

I have the same error message with Openmoko's official cross-compiler on my Debian etch. I think I can safely assume the problem is the same: libtool is linking RunningBear's libc with the system's own libc. To illustrate:

$ PATH=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin:$PATH make
[...]
libtool --mode=link cc -o libdl.la dlfcn.lo -rpath /usr/local/lib
cc -shared  .libs/dlfcn.o   -Wl,-soname -Wl,libdl.so.0 -o .libs/libdl.so.0.0.0
/usr/local/openmoko/arm/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/../../../../arm-angstrom-linux-gnueabi/bin/ld: errno: TLS definition in /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib/libc.so.6 section .tbss mismatches non-TLS reference in .libs/dlfcn.o
/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/lib/libc.so.6: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [libdl.la] Error 1

But then if I run:

$ PATH=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin:$PATH cc -shared -nostdlib .libs/dlfcn.o   -Wl,-soname -Wl,libdl.so.0 -o .libs/libdl.so.0.0.0

It links like a charm. It may be worth noting that surprisingly, "-Wl,-nostdlib" fails, whereas it's supposed to be an argument for the linker.

But the actual issue is with libtool, which strips this argument out from the command line:

$ PATH=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin:$PATH libtool --mode=link cc -shared -nostdlib -o libdl.la dlfcn.lo -rpath /usr/local/lib
cc -shared  .libs/dlfcn.o   -Wl,-soname -Wl,libdl.so.0 -o .libs/libdl.so.0.0.0

or again:

$ PATH=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/bin:$PATH libtool --mode=link cc -shared -Wl,-nostdlib -o libdl.la dlfcn.lo -rpath /usr/local/lib
cc -shared  .libs/dlfcn.o   -Wl,-nostdlib -Wl,-soname -Wl,libdl.so.0 -o .libs/libdl.so.0.0.0

keeps the link-time "-nostdlib" argument but still fails to link.

Therefore, I don't know what the actual fix is. I suppose I'll just supply a modified copy of the libtool script along with the libc then...

[ppronchery]

The undocumented (?) "-Xcompiler" flag allows one to force an argument. I spent a full week looking for it, until I managed to find it reading libtool's script... Please "svn update" and try again, I think it should work.

It enables me to build the libc with Openmoko's cross-compiler, but not other applications yet. I'm therefore leaving the bug opened.

[vcaron]

Bravo ! Works here.

[ppronchery]

Nice, thanks! I am still blocked somewhere with the Openmoko cross-compiler, but it's a different issue now. I am closing this one.