Re: linking correct libc

[ng at piments dot com]

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