linking correct libc

ng@piments.com ng@piments.com
Sat May 30 12:37:00 GMT 2009


Yann E. MORIN wrote:
> Peter,
> All,
> 
> On Tuesday 26 May 2009 09:02:13 ng@piments.com wrote:
>>> If it is really an ARM file, you can run again, but setting:
>>> LDFLAGS="-L/back/ts/root2/usr/lib/ -v -Wl,--verbose"
> [--SNIP--]
>> 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
> 
> Look at that: you've got a libc.so in your root2 tree!
> - Where does it come from?
> - How did you construct your root2 tree?
> 
THANK YOU! That was the problem. It now compiles fine with ct-ng.

> The cross-gcc expects to find its libc.so in its sysroot directory (which
> it finds automagically). 
I've never been a fan of magic in science and computing. I've always 
found well documented method more reliable ;)

If it finds a libc.so elsewhere, then all its
> internal logic is then completelt broken. 

Well this maybe an area for some simple improvement in the internal 
logic. It clearly knows when it finds something whether it is in 
sys-root or not. If this causes breakage is there any reason not to make 
only search in sys-root or at least display a warning if it picks up 
libc.so somewhere else?

Since I am not familiar with the internal workings of cross-tool I saw 
nothing wrong with it picking up a file in my arm tree. It seemed fine 
to me. I saw no mention of this "magic" sys-root behaviour in the doc so 
I had no reason to think this was a problem.

 > Remove that file, and see if
> it fixes it.
> 
> Usually, to build a "rootfs", you'd do something like (replace with adequate
> values, obviously!, and iterate for all your packages):
>   cd my-package-1
>   ./configure --prefix=/usr --build=i686-pc-linux-gnu   \
>               --host=arm-unknown-linux-gnueabi          \
>               --option1 --option2 [...]
>   make
>   make install DESTDIR=/back/ts/root2
>   cd ..
> 
> Once you're done, your root2 will contain all the files installed by your
> packages, and only those. It should *not* contain files from the toolchain
> (from the syysroot, notably). So it is not suited for direct usage.
> 
> You would then use the script provided with crosstool-NG that is specifically
> used to complete your root-dir structure with the necessary files:
>   arm-unknown-linux-gnueabi-populate -v    \
>       -s /back/ts/root2                    \
>       -d /back/ts/root2-full
> 
> Then, root2-full can be used as input to build file system images for your
> target (eg. mksquashfs, mkfs.jffs2and so on...), or can be used as an
> NFS-root. Of course, your root2 will still only contain the files installed
> by your packages.
> 
> This way, you achieve two main goals:
> - you don't modify the sysroot, so your toolchain can be reused to build
>   other things;
> - your root-dir contains only the files installed by the packages, and can
>   thus be considered "pure".
> 

Thanks I was aware of the process but did not realise ct-ng was intended 
only to create a virgin root fs image or that the presence of some 
library files that are appropriate to the final image could disrupt the 
cross compiler.

Maybe a note on this could be added to the section entitled "using the 
cross-compiler.


> Regards,
> Yann E. MORIN.
> 
> PS. Be patient, if no one answers, it can be for at least two reasons:
> - no one has the answer, in which case saying so is just a waste
>   of bandwidth;
> - someone might have the answer, but is not reading his/her mails
>   due to other duties.
> 
> Remember, this is a volunteer-based effort, and you can't expect anyone
> to abide by your desires. Repeating the same problem again and again
> will surely not help.
> 
> YEM.
> 
I've certainly been patient (and persistent) , I've been working on this 
issue for nearly three weeks.

Rather than repeating the same thing I intended to provide further 
information on the problem and to demonstrate that I had thoroughly 
investigated what was happening.

I'm sure someone with your talents has lots of other duties and I am 
very grateful for your help in finding the cause of this problem.

Cordialement, Peter.





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



More information about the crossgcc mailing list