On Fri, 2010-12-17 at 13:24 +0000, Wookey wrote:
+++ Amit Mahajan [2010-12-17 17:19 +0530]:
On Fri, 2010-12-17 at 11:30 +0000, Andrew Stubbs wrote:
I checked the wiki and other links but could not find a related document.
You are right that this process is not properly documented. That's largely because because it's either very slow (emulated) or very difficult (cross). If you do have some fast-enough hardware of the right type then it's fairly tractable, although toolchain-defaulting is still an awkward process requiring a flavoured rebuild of the toolchain. We do at least have that in place now though.
I'll this to mey list of 'missing wiki pages'. We should at least document the flavoured-native-rebuild process as that is in place, even if it doesn;t help in your case.
Hi Wookey,
If you can give me some short comments on how you do flavoured-native-rebuild, I can possible customize it for my scenario and possible get back with some good document, that might be helpful for others too. Just a thought.
Thanks for your help. The procedure you mentioned looks good. But I have 2 points here:
- Right now I do not have access to board. I think probably I can use
QEMU for simulating my hardware.
- Compiling each package individually will be a long process. I wonder
if Ubuntu has something like ALIP (ARM linux internet platform), which can be readily used with scratchbox.
We are working on this. Debian/Ubuntu was never designed for cross-building so a fair amount of work is needed to make this an easy, slick process.
What you probably actually want is for someone else to have already built a no-VFP flavour of the distro that you could just use. Presumably that would be fine? (Debian's existing armel port might be of use, unless you also need everything to be built for v7, or to be actually using the ubuntu sources for some reason?)
Yes, if some has a prebuilt noVFP flavour, I can use that but it need to be build for ARM v7 only, as my target is v7 platform only :)
Ubuntu is not a special requirement for me, so I have already explored armel port of Debian too, but found the same restrictions as you mentioned.
My belief is that in practice most people would be satisfied if a small number of flavours (v5, v6, v7 noVFP) were pre-built. Shout if that's not true for you.
As and end user I agree here with you totally. But from a developer's perspective I would like to have a system which I can build from scratch and see how it works, so that I can customize it readily for future.
A common example is ALIP. It was well maintained, with some good preliminary tutorials. Its can be customized easily for various configs.
Nevertheless there are enough awkward cases that making it easy to bootstrap a new flavour without relevant hardware is an important goal (a-la ALIP/AEL). For this to work we need the main core of 200-odd packages to cross-build properly, for circular build-dependencies to be breakable, and for cross-build tools to be able to reliably do the right thing with dependencies. About half of those 200 packages do now cross (sometimes with not-yet-merged patches), circular build-dependencies are being removed (with staged builds), and the cross-building tools and meta-data are being improved so that the process is automable and reliable. That last process depends on multiarch to be fully implemented in order to have cross-dependencies correctly described in package metadata.
For this stuff to stay working we also need continuous cross-build testing, otherwise it will bitrot.
I expect this to be a working, demonstrable, process within the next couple of months, but from a patched set of sources because various aspects can't go in the main repo yet.
I am trying to keep this page https://wiki.linaro.org/CrossBuilding as a good overview. That has a currently more-or-less empty 'Rebuilding everything for a new ABI/flavour section. I'll fill that out now.
Wookey
Hmm, ok let me see this page. Thanks for help!