Hi,
I want to build linaro-netboook filesystem from *sources*, as I need a filesystem build without VFP support.
I checked the wiki and other links but could not find a related document.
Can anyone please point me to directions on how to do the same?
On 17/12/10 08:01, Amit Mahajan wrote:
I want to build linaro-netboook filesystem from *sources*, as I need a filesystem build without VFP support.
I checked the wiki and other links but could not find a related document.
Can anyone please point me to directions on how to do the same?
I don't know if there's an official way to do that, but here's what I would do:
1. Find a board you can run the existing installation on. Cross building packages is hard, so it'll be easier to bootstrap it this way.
2. On this board, download the compiler sources:
apt-get source gcc
3. Tweak the compiler configuration flags in the debian directory so that they set up the VFP as you want it, and build the compiler:
sudo apt-get build-dep gcc dpkg-buildpackage gcc*.dsc
4. Install the new gcc into the build board (I would recommend doing this work in a chroot incase something goes wrong ...):
dpkg ..... gcc*.dep
5. Squirrel away the newly built .deb files.
6. Repeat for all packages until you have no packages depending on VFP in your system. Most won't require any reconfiguration, but you never know. It's probably best to start with glibc, and then other libraries, just to make sure the headers and configure tests are right. (Maybe non-VFP kernel headers also, but you'll need to run a VFP-enabled kernel until you're done rebuilding everything.)
Your build file-system should now run on your netbook, although it'll be chock full of -dev packages, so you might have to clean it up a bit.
This should work because the default ARM EABI is the same whether you use VFP, or not. If/when we choose to switch to the hard-fp EABI variant (in theory, it's more efficient), then tricks like this will be more difficult.
Hope that helps
Andrew
On Fri, 2010-12-17 at 11:30 +0000, Andrew Stubbs wrote:
On 17/12/10 08:01, Amit Mahajan wrote:
I want to build linaro-netboook filesystem from *sources*, as I need a filesystem build without VFP support.
I checked the wiki and other links but could not find a related document.
Can anyone please point me to directions on how to do the same?
I don't know if there's an official way to do that, but here's what I would do:
- Find a board you can run the existing installation on. Cross building
packages is hard, so it'll be easier to bootstrap it this way.
On this board, download the compiler sources:
apt-get source gcc
Tweak the compiler configuration flags in the debian directory so
that they set up the VFP as you want it, and build the compiler:
sudo apt-get build-dep gcc dpkg-buildpackage gcc*.dsc
- Install the new gcc into the build board (I would recommend doing
this work in a chroot incase something goes wrong ...):
dpkg ..... gcc*.dep
Squirrel away the newly built .deb files.
Repeat for all packages until you have no packages depending on VFP
in your system. Most won't require any reconfiguration, but you never know. It's probably best to start with glibc, and then other libraries, just to make sure the headers and configure tests are right. (Maybe non-VFP kernel headers also, but you'll need to run a VFP-enabled kernel until you're done rebuilding everything.)
Your build file-system should now run on your netbook, although it'll be chock full of -dev packages, so you might have to clean it up a bit.
This should work because the default ARM EABI is the same whether you use VFP, or not. If/when we choose to switch to the hard-fp EABI variant (in theory, it's more efficient), then tricks like this will be more difficult.
Hope that helps
Andrew
Hi Andrew,
Thanks for your help. The procedure you mentioned looks good. But I have 2 points here: 1. Right now I do not have access to board. I think probably I can use QEMU for simulating my hardware.
2. 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.
- Right now I do not have access to board. I think probably I can use
QEMU for simulating my hardware.
Yes, I expect so, but it won't be fast!
Does the kernel not have a VFP emulation mode that might make the existing binaries work on your netbook, at least well enough for bootstrapping purposes? Just a thought ... it might be better than QEMU?
- 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.
That would be nice, but I don't know of such a thing, and would it work for builds in a custom environment?
Anyway, here's another top-tip: use distcc. This is a tool that gives you a 'virtual' compiler. It does all the preprocessing and linking using the native tools (in QEMU, in your case), but sends the preprocessed source to a distcc server on another machine for the actual compilation job.
The distcc server can be another ARM machine, but equally it can be a PC with a suitable ARM cross compiler.
You can set up multiple distcc servers, each configured to run multiple compile jobs, if you wish, and then run the build with DEB_BUILD_OPTIONS=parallel=2 (or whatever) in the environment, and maybe get a performance boost, depending how QEMU performs at the preprocessing.
Back in a former job, I used to have 6 SH-64 boards running package builds via distcc, with the compilers running on 8 x86 build servers, and I could rebuild the entire distro in one night. Of course, that was only a small distro I put together myself - nothing on the scale of Ubuntu, and the boards were faster than QEMU, probably.
Distcc is often mentioned in conjunction with ccache, but caching object files isn't really very interesting if you only build each package once. There might be some small advantage in speeding up repeated configure tests, I suppose, but I suggest not bothering with it.
Hope that helps
Andrew
On Fri, 2010-12-17 at 12:20 +0000, Andrew Stubbs wrote:
- Right now I do not have access to board. I think probably I can use
QEMU for simulating my hardware.
Yes, I expect so, but it won't be fast!
Does the kernel not have a VFP emulation mode that might make the existing binaries work on your netbook, at least well enough for bootstrapping purposes? Just a thought ... it might be better than QEMU?
Yes, my kernel right now doesnot support VFP at all.
- 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.
That would be nice, but I don't know of such a thing, and would it work for builds in a custom environment?
ALIP is a bit tricky thing, but if you understand their build process, its very easy to customize it. Right now i use its v7 without vfp variant.
Anyway, here's another top-tip: use distcc. This is a tool that gives you a 'virtual' compiler. It does all the preprocessing and linking using the native tools (in QEMU, in your case), but sends the preprocessed source to a distcc server on another machine for the actual compilation job.
The distcc server can be another ARM machine, but equally it can be a PC with a suitable ARM cross compiler.
You can set up multiple distcc servers, each configured to run multiple compile jobs, if you wish, and then run the build with DEB_BUILD_OPTIONS=parallel=2 (or whatever) in the environment, and maybe get a performance boost, depending how QEMU performs at the preprocessing.
Back in a former job, I used to have 6 SH-64 boards running package builds via distcc, with the compilers running on 8 x86 build servers, and I could rebuild the entire distro in one night. Of course, that was only a small distro I put together myself - nothing on the scale of Ubuntu, and the boards were faster than QEMU, probably.
Distcc is often mentioned in conjunction with ccache, but caching object files isn't really very interesting if you only build each package once. There might be some small advantage in speeding up repeated configure tests, I suppose, but I suggest not bothering with it.
Hope that helps
Andrew
This looks very nice. I will try to establish this environment over the weekend.
Thanks for great help!
+++ 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.
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?)
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.
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
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!
-
Amit Mahajan -
Andrew Stubbs -
Wookey