Re: !(fun) with tls

[Colin Paul Gloster <Colin_Paul_Gloster at ACM dot org>]

On Fri, 2 Jun 2006, NZG wrote:

"I'm trying to build a cross compiler for a specific debian build we use 
on our 
embedded 568 SBC's.

[..]

Start it up and it builds the cross toolchain perfectly, voila.

I copy my new toolchain into my SDK and build a test program, no problem.

I copy the libc from my target 
libc-2.3.2.so

and attempt to link against it: [..]
[..]"

If you compile and link without using the LibC from your target, will the 
binary successfully run on your target?

"[..]

[..]
More importantly, the cross compiler can't link against the pthreads library 
of this version
libpthread-0.10.so

Attempting to do so yields:

gcc-3.4.3-glibc-2.3.2/i386-unknown-linux-gnu/bin/i386-unknown-linux-gnu-gcc 
modreg.o -Wl -Llib/dynamic ../../lib/static/libmodbus.a -o 
modreg -lpthread-0.10
lib/dynamic/libpthread-0.10.so: undefined reference to 
`__libc_fork@GLIBC_2.1.2'

Which looks like utter madness to me,
GLIBC_2.1.2? where did that come from?
Neither the host, the target, or the cross compiler uses 2.1.2.

[..]"

It is common for libraries to contain many "@GLIBC_.+" references with 
different versions for different symbols. Different versions are not 
always incompatible. An unrelated example on Red Hat Fedora Core GNU/Linux
2.6.14-1.1656_FC4smp:
"strings /usr/lib/libz.so | egrep GLIBC_.+
GLIBC_2.1.3
GLIBC_2.3.4
GLIBC_2.1
GLIBC_2.0".

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