+++ 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/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
