Quote:
Originally Posted by twobob
|
Nope.
You want to build a (e)glibc based system and that is a gcc-4.2 series tool-chain.
gcc-4.2 series is too old to build a current (e)glibc system library.
The CS/MG tool chain should be usable, otherwise we can use the Ubuntu-Linaro tool chain (a gcc-4.6 one).
When I wake tomorrow - I will check if I put one of those on the KeK resource server, if not, I will put one there.
- - - -
Now, the question of getting a native tool-chain built for your Buildroot generated rootfs . . . .
The short answer: We get to do it ourselves (for the first time).
The longer answer:
Buildroot 2012.08 will be out within a couple of weeks - anything other than bug-fixes will not be added to it during those weeks.
In Buildroot 2012.11 - that "Native build tools on target" should be moved to "depends on BROKEN".
Which is just fine, it can only generate a uClibc based set of native tools on the target (when, if, it works and your extra lucky).
I have exchanged (on the BR M.L.) a few posts with the author of ct-ng . . . .
At the moment, ct-ng isn't ready to take over for the internal BR tool-chain generation in all situations, but the above BR change will mean that the internal one will not be replaced earlier than 2013.05.
So ct-ng **might** be "ready" within that time frame.
In addition to the "not ready" items of ct-ng . . . .
It has a config menu entry of: cross-native
but that entry doesn't have any code behind it at the moment (and is not likely to grow any, unless someone submits patches to add it).
We **could** patch BR-2012.08 to compile and cross-compile (both host and target) the tools and libraries required to support a tool-chain build as new "packages" rather than part of the "Broken" tool-chain generation.
Then we **could** patch ct-ng to cross-compile binutils, (e)glibc, and a bootstrap (I.E: "First stage") gcc build.
There is a good chance of getting those patches accepted by both BR and ct-ng.
Now, to finish up the gcc build (stages two and three) -
That would have to be done by "cherry picking" the rootfs built by BR into a rootfs that can be run under emulation and hand-off the second and third stage gcc build to the emulator.
Once that is done, then the new, tested, native, gcc can build the final native binutils and system library(ies) under the same emulator instance.
Pant, pant, pant, pant . . . .
Sounds like a lot of Makefile writing to me, but working with the two project teams makes it much more likely that it could happen.
It was a chore just writing this description, but the Makefile snippets that need to be patched into the two systems are just the things we would have to do by hand to add a tool-chain to your rootfs.