Re: Cross-compiling debian packages for arm - an automated way?
On Wed, Aug 14, 2013 at 03:54:07PM -0500, Bill Gatliff wrote:
> > I'm using SLIND with bitbake. SLIND is an implementation towards the
> > vision of Crush (but predates it), hacky at places, but it works.
> > Bitbake is the build system of OpenEmbedded.
>
> Would running debian-arm* under qemu work better? Then you could go for
> native compilation...
Hmm, that's a good idea. At the time SLIND was started, this option was
not available. Today, it's a good alternative. Some issues would have to
be clarified (such as performance, using multiple cores, preparing a
rootfs, controlling the build process outside of qemu). The disadvantage
of the qemu approach is that it requires a Debian port for the target
architecture. With SLIND, one can cross-compile on any Debian host /
chroot. Some use cases:
* I can cross-build SLIND packages for arm-linux-gnu OABI target on
wheezy i386. With qemu, I'd have to stick to lenny, since OABI has
been discontinued. This would mean that you can't e.g. use a newer
compiler (which you might want to due to new features or kernel).
* I could cross-build SLIND packages for any target not supported by /
deviating from Debian as long as I have a cross-compiler for it. This
is practically not possible with qemu (unless you bootstrap that new
port, which I wouldn't do).
* For an embedded target, you'll probably want to touch Debian packages
anyway (dropping docs, reducing essentials, stripping perl, etc.).
If you don't, buildd your Debian subset under qemu, and you are done
for this time. If your installations live longer than Debian version /
port, you'd have to maintain it yourself.
If you do, you have to maintain your fork with either approach. So
qemu would only save you building a cross-compiler -- but that is not
that much effort with Debian.
So, it's a matter of bringing the target to Debian vs. bringing Debian
to the target. In general, I'd prefer the former. Given that Debian is
about tools, it helps a lot. For one-time projects, I could consider
qemu; however, OpenEmbedded would fit as well, or better. That said, I
rarely have one-time projects of that kind.
With kind regards,
Baurzhan.
Reply to: