linking correct libc

ng@piments.com ng@piments.com
Tue May 26 16:34:00 GMT 2009


Yann E. MORIN wrote:
> Peter,
> All,
> 
> On Tuesday 26 May 2009 07:07:28 ng@piments.com wrote:
>>    CFLAGS="-march=armv4t"  CPPFLAGS="-I/back/ts/root2/usr/include" 
>> LDFLAGS="-L/back/ts/root2/usr/lib/"  make
>> arm-unknown-linux-gnueabi-gcc -march=armv4t -Wall -Wstrict-prototypes 
>> -fpie -I/back/ts/root2/usr/include -DHOSTS_ACCESS -DCHECK_PORT 
>> -DIGNORE_SIGCHLD    -DFACILITY=LOG_DAEMON   -c -o portmap.o portmap.c
>> arm-unknown-linux-gnueabi-gcc -march=armv4t -Wall -Wstrict-prototypes 
>> -fpie -I/back/ts/root2/usr/include -DHOSTS_ACCESS -DCHECK_PORT 
>> -DIGNORE_SIGCHLD    -DFACILITY=LOG_DAEMON   -c -o pmap_check.o pmap_check.c
>> arm-unknown-linux-gnueabi-gcc -march=armv4t -Wall -Wstrict-prototypes 
>> -fpie -I/back/ts/root2/usr/include -DHOSTS_ACCESS -DCHECK_PORT 
>> -DIGNORE_SIGCHLD    -DFACILITY=LOG_DAEMON   -c -o from_local.o from_local.c
> 
> So far, all good.
> 
>> arm-unknown-linux-gnueabi-gcc -L/back/ts/root2/usr/lib/ -pie  portmap.o 
>> pmap_check.o from_local.o  -lwrap -o portmap
> 
> All input .o files should be ARM files, they got build just above. Just
> check libwrap is an ARM binary too, just to be sure it got cross-compiled:
> file /back/ts/root2/usr/lib/libwrap.so*

file /back/ts/root2/usr/lib/libwrap.so*
/back/ts/root2/usr/lib/libwrap.so:       symbolic link to `libwrap.so.0'
/back/ts/root2/usr/lib/libwrap.so.0:     symbolic link to `libwrap.so.0.7.6'
/back/ts/root2/usr/lib/libwrap.so.0.7.6: ELF 32-bit LSB shared object, 
ARM, version 1 (SYSV), dynamically linked, not stripped


> 
> If it is really an ARM file, you can run again, but setting:
> LDFLAGS="-L/back/ts/root2/usr/lib/ -v -Wl,--verbose"
> 
> The output is quite verbose, but you'll see exactly what ld is trying
> to do...
> 
attempt to open 
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/libgcc_s.a 
failed
attempt to open 
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/lib/libgcc_s.so 
succeeded
-lgcc_s 
(/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/lib/libgcc_s.so)
attempt to open /back/ts/root2/usr/lib//libc.so succeeded
opened script file /back/ts/root2/usr/lib//libc.so
opened script file /back/ts/root2/usr/lib//libc.so
attempt to open /lib/libc.so.6 succeeded
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
cannot find /lib/libc.so.6
collect2: ld returned 1 exit status
make: *** [portmap] Error 1


>> So I would say : no, the toolchain is not working correctly in this case.
> 
> Not so sure... ;-)
> 
>> 1/ It is really finding /lib/libc.so.6 (ie the host x86 library) as 
>> indicated by the output but contrary to the -print-search-dirs paths.
> 
> Maybe, just check libwrap, as stated above.
opened script file /back/ts/root2/usr/lib//libc.so
attempt to open /lib/libc.so.6 succeeded

Maybe I should be taking this output to be the truth, it really is 
looking in /lib?

YES!

pwd
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib
rm libc.so.6

attempt to open /back/ts/root2/usr/lib//libc.so succeeded
opened script file /back/ts/root2/usr/lib//libc.so
opened script file /back/ts/root2/usr/lib//libc.so
attempt to open /lib/libc.so.6 succeeded
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
/back/ts/ct-ng/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/bin/ld: 
cannot find /lib/libc.so.6
collect2: ld returned 1 exit status
make: *** [portmap] Error 1


Right, finally something concrete. So now the question is why.

:?

regards.


> 
>> 2/ It is looking in the right place but finding something different to 
>> what is expected.
> 
> EABI and endianness come to mind. The verbose ld logs, above, will
> tell.
> 
>> 3/ It is finding a good libc but erroneously calling it incompatible.
> 
> Nope.
> 
> Regards,
> Yann E. MORIN.
> 


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



More information about the crossgcc mailing list