This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |