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: crosstool-NG 1.14.0 is out



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


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