Re: cross-compilation pango
+++ Lennart Sorensen [2013-06-07 11:46 -0400]:
> On Fri, Jun 07, 2013 at 04:34:00PM +0100, Wookey wrote:
> > +++ Lennart Sorensen [2013-06-07 10:55 -0400]:
> > > and anything using the horrors
> > > of autoconf and company is just about doomed to failure when attempting
> > > to cross compile.
> > I have to disgree here. autconf's cross-build support is good and
> > generally works pretty well. Of the many build systems out there it is
> > one of the least-bad in this regard.
>
> I can't think of much that is worse (maybe ant is a worse horror).
Ant, maven, and makemaker have no real concept of crossbuilding and
thus are useless/just get in the way. Perl's build system does support
cross-building but only in a horribly inconvenient and
labour-intensive fashion. The only ones that work icely IME are
autoconf and cmake. I've not tried other things such as scons. Other
special purpose or DIY systems usually ignore the issue and are no help.
> gcc since 4.3 hasn't been able to be cross compiled due to autoconf
> issues with libstdc++. It insists on running binaries to determine the
> target system's features and when you are not on a target system you
> can't do that.
gcc and libstdc++ are cross-built on a daily basis. It's complicated,
but it definitely works.
> And while you can use the environment to define the autoconf answers
> for most things, there are exceptions where there is no way to provide
> the answer.
Autoconf provides mechanisms both to prevent running tests/wrong-arch
binaries when cross-building, and for providing cached answers. That's
sufficient to cross-build things reliably so long as you know those
answers for the target environment (which for Debian glibc linux at
the autoconf level you generally do (how big is a float?, does glibc
have function foo?).
Some of these things _have_ to be cached/pre-described. There is no
other way to find the size of a float on the target architecture, for
example, so when crossing only pre-declared answers can sensibly work,
so you need this mechanism. Using it for other things which could, in
theory by programatically be determined, but are not in this setup, or
only could be with qemu, makes sense to me, and works well in practice.
And if you _do_ need to change the provided answers for some reason,
we have one single file where it is defined so the change propogates
nicely. Yes, it's not as reliable as build-time checks, but it works
well in practice, and I hardly had to make any charges for arm64
bootstraping.
Build systems that determine such info without running (wrong-arch)
tests would be better, but as soon as you make it declarative you're
back to essentially the same mechanism as autoconf cache files
provide. Do any such build-systems exist? cmake may be better in this regard?
> Now with multiarch and qemu, you are starting to be able to actually run
> the autoconf crap on qemu making you able to actually run the target code
> to determine what settings to use, but it sure isn't thanks to autoconf
> that it is becoming possible.
Everything I have crossbuilt so far for arm64 (170-odd packages,
enough to bootstrap the arch) did not use qemu to run tests (because
it didn't exist then). So yes that's a handy feature, but it's not
necessary to get reliable cross-building for autoconfed packages (most
of the base-system packages use autoconf).
> To some extent this is starting to allow
> crosscompiling through target system emulation, rather than pure cross
> compiling with no access to a target system.
We can do both and they both work, at least in a Debian context.
I'm not saying I _like_ autonconf. It's cryptic and overcomplicated
and it's cross-support does to a large degree consist of saying "can't
check that - tell me the answer instead", I'm just saying that it has
enough mechanism to reasonably reliably cross-build the base system,
which is a lot more mechanism than most other build systems.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: