Yan Seiner wrote: > I hope someone can point me at the right FM.... FM? > arm-linux-gcc main_nx.c -I../Lib -I../../microwin/src/include > -I/home/local/panel/arm//ts7300-deb/usr/include > -L/home/local/panel/arm//ts7300-deb/lib > -L/home/local/panel/arm//ts7300-deb/usr/lib -nodefaultlibs -o swfplayer > ../Lib/libflash.a -ljpeg -lnano-X -lm -lstdc++ -lz -lc > /usr/local/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/lib/gcc-lib/arm-linux/3.3.4/../../../../arm-linux/bin/ld: > skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6 > /usr/local/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/lib/gcc-lib/arm-linux/3.3.4/../../../../arm-linux/bin/ld: > cannot find /lib/libc.so.6 > collect2: ld returned 1 exit status I would start with -v to find out the exact linker command, and then -Wl,-verbose to watch the linker process the arguments to find out where this bogus reference to the host libc is coming from. I've seen this kind of thing happen when libtool is being used and there's a .la file somewhere that contains something in dependency_libs that's not appropriate or downright incorrect, but that seems irrelevant here. Also, use of -nodefaultlibs seems kind of suspicious here. If the cross-toolchain is functioning correctly, you should be able to link normally, just like you would with a native compiler, without having to use -nodefaultlibs and without having to manually specify things like -lc -lstdc++ which the compiler-driver is supposed to handle. If that was added as an attempt to get rid of this reference to the host libc, then it sounds like the wrong approach; figure out where the reference is coming from first. If this binary contains C++ objects, then consider linking with arm-linux-g++ instead of gcc. That may mean using arm-linux-gcc -c to first compile main_nx.c and then g++ to link it. Brian
