I’ve always liked the Scratchbox approach to cross-compiling. Run ./configure && make and you have an ARM binary, no need to explicitly tell the configure we are cross-compiling nor fix the bad behaving build scripts.
MeeGo doesn’t provide an SDK for the (ARM) platform. There’s an SDK for building Qt applications and there’s an QEMU for emulating the ARM device environment. For building the lower level components (Qt itself, GStreamer, etc) you are expected to use OBS. OBS is a very good build infrastructure tool, especially as you can link your own OBS to upstream OBS instances like MeeGo or OpenSUSE and have your OBS build only your own components or modified upstream components.
But OBS is a bit overkill when you are developing your own component that you don’t want to be a part of anything bigger yet. The OBS client side tool, osc, allows you to build components locally in a chroot but still you need an OBS account and those aren’t automatically available for everyone, not even in the community OBS.
I took the chroot created by osc build and modified it a bit with the help from stskeeps @ #meego-arm. The produced chroot is capable of building ARMv7 hard-float binaries without OBS or OBS account. It includes a minimal set of dependencies to make it smaller for easy download (it’s still 162MB), and the project specific dependencies can be installed normally with zypper from the standard MeeGo repositories.
The benefit from using a chroot over a QEMU image is the installed speed tools; many of the components taking time during a build are actually x86 binaries. These include e.g. bash, compilers and bzip2. Running these as emulated ARM binaries (or natively on an ARM hardware) would be much much slower.
I’ve used this approach with my own Qt + GStreamer project and it has been working well but that’s only a small use case so there can be all kinds of issues still. I use the same account inside the chroot and outside and bind mount my $HOME to the chroot so I can build project under my $HOME.
Current known issues:
- Zypper doesn’t find noarch packages (this is an upstream bug, not related to my chroot).
- Tested only on Debian Squeeze. At some point there was a linker issue on Ubuntu and I don’t know if that still exists.
- My instructions mention libqt4-devel although the package name is libqt-devel.
If you want to try it out, it’s available via BitTorrent at http://tuomas.kulve.fi/tmp/torrent/ (temporary location). After extracting the tarball, see the readme file in the root directory.
This is excellent news! Any chance of scripting the creation of the chroot in the future? Probably more space efficient than distributing the whole thing, and would allow for easy customisation/etc, which would be so awesome I can’t even begin to say :)
Yes, I already use a simple script to do part of the job and I’m planning to write a detailed wiki page about the setup later, if there’s interest for the chroot.
If anyone is having problems getting an account on the community OBS then there is something wrong – it’s open to anyone.
The main reason we enable accounts on a case-by-case basis is that we still have people who think they can develop closed code on it :)
I like the idea of the chroot and use that approach myself – what I’d like to see is a simple way for people to regenerate this using “osc build” and eventually to see that chroot to support updates.
Could I ask you to document what the chroot should provide ? ie expand on “modified it a bit”.
Then we can work on a maintainable way to develop and update it. That way people will know that the rootfs they download really does come from meego.com and isn’t an unverifiable 160+Mb binary.
I don’t what the chroot should provide :) I would like to hear comments about that. I tried to make it quite small (without increasing the amount of work needed to do it) for easier download. For convenience it might be nice for it to include all the common dependencies for MeeGo application development.
I’ve been using root inside the chroot for zypper install etc., but it might be possible to use a normal account only, which would be handy as then there wouldn’t be any root owned files inside it.
The downside in using “osc build” is the need for the OBS account. Of course it is a must for everybody to be able to reproduce what I’ve done but there also must be ready made images that anybody can use for any (closed source or open source) stuff without asking in IRC for somebody to enable the account.
About updating the chroot. “zypper update” should work there just like in any other environment, I would guess. I haven’t really test that. Of course having mixed x86/ARM binaries with QEMU might cause some upgrade problems that doesn’t emerge in native environments. And QEMU has always something unimplemented.
I’ll write some detailed wiki instructions when I have something better than a mini laptop and a 2G connection. But shortly, I create the chroot by building zypper from my OBS home project with “osc build”. I guessed that building that provides the basic dependencies I want. Then I removed some localisation stuff, abuild user and extra qemu binaries (for non-ARM archs), and maybe something else, I use a small script for that. That is already 400MB off. After that I add the readme and the run-me-first script in the root and tar it. The run-me-first script does the modifications, i.e. modify prompt to mention chroot, add the user account, force zypper and RPM architecture to ARMv7el, and swap the x86 RPM with ARM RPM binary. That’s pretty much it.
Here’s the link to the initial instructions page:
http://wiki.meego.com/ARM/chroot