Re: linking correct libc

[ng at piments dot com]

ng@piments.com wrote:
> Hi,
>
> trying --sysroot was one of my desperate attempts to get some sense out 
> of this toolchain. I have now dumped the idea.
>
>
>  CFLAGS="-march=armv4t" CPPFLAGS="-I/back/ts/root2/usr/include" 
> LDFLAGS="-L/back/ts/root2/usr/lib/ 
> -L/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib" 
> make
>
>
> ...
> /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: *** [pmap_dump] Error 1
> pr
>
>
> adding -nostdlib stops it finding the host libc but stops it finding any 
> libc:
>
>
>  CFLAGS="-march=armv4t" CPPFLAGS="-I/back/ts/root2/usr/include" 
> LDFLAGS="-L/back/ts/root2/usr/lib/ 
> -L/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib 
> -nostdlib" make
>
> ...
>
> /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: 
> warning: cannot find entry symbol _start; defaulting to 000080b4
> pmap_dump.o: In function `main':
> pmap_dump.c:(.text+0x28): undefined reference to `memset'
> pmap_dump.c:(.text+0x3c): undefined reference to `htonl'
> pmap_dump.c:(.text+0x4c): undefined reference to `htons'
> pmap_dump.c:(.text+0x60): undefined reference to `pmap_getmaps'
> pmap_dump.c:(.text+0x7c): undefined reference to `getrpcbynumber'
> pmap_dump.c:(.text+0x104): undefined reference to `printf'
> pmap_dump.c:(.text+0x12c): undefined reference to `fclose'
> pmap_dump.c:(.text+0x148): undefined reference to `perror'
> pmap_dump.c:(.text+0x17c): undefined reference to `stdout'
> pmap_dump.o: In function `protoname':
> pmap_dump.c:(.text+0x1d8): undefined reference to `sprintf'
> collect2: ld returned 1 exit status
> make: *** [pmap_dump] Error 1
>
>
>  file pmap_dump.o
> pmap_dump.o: ELF 32-bit LSB relocatable, ARM, version 1 (SYSV), not 
> stripped
>
>
>  file 
> /back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib/libc.so.6 
>
> /back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib/libc.so.6: 
> symbolic link to `libc-2.9.so'
>
> file 
> /back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib/libc-2.9.so 
>
> /back/ts/ct-wkg//x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/lib/libc-2.9.so: 
> ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked 
> (uses shared libs), for GNU/Linux 2.6.29, not stripped
>
>
> So the two basic issues remain: why does it find /lib/libc.so.6 at all 
> and why can't it find (or use) the library that exists in the libdir 
> explicitly included with -L ??
>
>
> This one issue has consumed a lot of time , any help would be appreciated.
>
> regards, Peter.
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq

Hi Yann,

I'll repost this one from last week as a recap since I don't seem to 
have got any closer to the answer.

With help from your I have established with --print-search-dirs that the 
library search path is correct and includes the directory with the 
correct libc.so.6 and does NOT include the host systems /lib.

libraries: 
=/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.3.2/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/lib/arm-unknown-linux-gnueabi/4.3.2/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.3.2/../../../../arm-unknown-linux-gnueabi/lib/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/lib/arm-unknown-linux-gnueabi/4.3.2/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/lib/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/usr/lib/arm-unknown-linux-gnueabi/4.3.2/:/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/usr/lib/

So why is the linker picking up the host's libc, rejecting it, and than 
failing to find anything else?

The last 10 days has allowed me to confirm that what originally appeared 
to be happening is in fact happening but I am still no closer to 
building this package with crosstool-ng.

The crux of the problem seems to be here:

cat 
/back/ts/ct-wkg/x-tools/arm-unknown-linux-gnueabi/bin/../arm-unknown-linux-gnueabi//sys-root/usr/lib/libc.so
 /* GNU ld script
     Use the shared library, but some functions are only in
     the static library, so try that secondarily.  */
 OUTPUT_FORMAT(elf32-littlearm)
 GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED (
 /lib/ld-linux.so.3 ) )

> Yes, correct. Those are paths relative to the sysroot, so gcc will 
hapilly find them.
> BTW, notice: ld-linux.so.3 -> EABI-era dynamic linker, good.

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

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

SO CLEARLY THE INCOMPATIBLE FILE IS THE HOST libc.so.6 NOT THE ARM ONE!

Why is it not using the sys-root one as you suggested it would be?

Thanks.


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