This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: linking correct libc


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]