This is the mail archive of the
crossgcc@sourceware.org
mailing list for the crossgcc project.
See the CrossGCC FAQ for lots
more information.
Re: crosstool-NG 1.14.0 is out
- From: Michael Zintakis <michael dot zintakis at googlemail dot com>
- To: Johannes Stezenbach <js at sig21 dot net>
- Cc: "Yann E. MORIN" <yann dot morin dot 1998 at free dot fr>, crossgcc at sourceware dot org
- Date: Thu, 08 Mar 2012 19:09:06 +0000
- Subject: Re: crosstool-NG 1.14.0 is out
- References: <201202010100.49177.yann.morin.1998@free.fr> <4F575EAB.1030308@googlemail.com> <20120308144656.GA30302@sig21.net>
The libc from your build system might have a dependency
on a minimal kernel version, so the statically built
toolchain might not run on very old systems.
Otherwise the static toolchain should be self-contained.
Unfortunately, I had to scrap that idea pretty swiftly :-(
As it turns out, what I was planning to do - "emulate" native-cross
toolchain in action blew up right in my face!
What I did was to build the toolchain with uclibc (the host environment
had glibc), then archived the whole toolchain directory and copied it
over to the host environment. Finally, with the help of qemu-static, a
bit of bin_fmt magic and adjusted path statement the toolchain was
executing perfectly. So far, so good, but...
When I tried to build a binary (tried to make & install zlib as it is a
farily good test on how things work out) it turns out the linker was
picking up my host glibc *as well as* the toolchain's uclibc dependency
files (i.e. <arch>-ldd -root /toolchain/sysroot was clearly showing
/lib/ld-Linux as well as /lib/ld-uClibc in addition to the monstrous
glibc's own libc.so). After trying to fix that for the best part of a
whole day yesterday - unsuccessfully - I finally gave up and I am now
using the whole cross toolchain as a proper cross toolchain, which is a
real pain as I have to manually compile and install all of the bloody
dependencies for what I need to compile for the target.
It wasn't all that bad though - I came up with an idea for Yann - I've
read the ct-ng readme file (part 5 I think it was) in which there is an
explanation of various possible scenarios for sysroot. I am planning to
do something similar to option 3 in that list - create an overlay
between a staging directory, say /some/place/overlay, which would be
read-write, and the toolchain's sysroot and map it to the old sysroot.
That way, I could write/install anything freely to the toolchain's
"sysroot without actually damaging that directory in any way, while
keeping the "written" stuff in a separate directory (the overlay). I'll
try that tonight and see where that takes me.
Are there any plans to implement cross-native in ct-ng?
--
For unsubscribe information see http://sourceware.org/lists.html#faq