lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

[apologies for carrying this thread on, but speaking as a frequent cross-compiler and former distro maker, I think the ways autoconf actually assists cross-compilation are not intuitive]

On Jul 19, 2012, at 9:18 PM, Dimiter 'malkia' Stanev wrote:

> I still don't get how autoconf works with cross compiling... Does it actually?

Yes. It was easier to cross-compile autoconfiscated packages than anything else in the ~2001 timeframe, and autoconf has improved since then. The real disasters were things like perl's config script.

> Ideally it should create small test executables and run them on the target platform... I doubt it's doing that...

It can't do that when cross-compiling. However, run-time behavior comes up less often than you'd think. The presence of an #include or #define is a feature of the cross-compiler, not the target. This can be tested at compile time: does "mipsel-linux-gcc -c foo.c" succeed and produce a foo.o? The presence of a symbol, or which library is needed for a symbol, can be tested at link time.

Back in ~2001, the most common problem was questions like sizeof(int), which I thought was only knowable at run-time.[1] For features like that, it was convenient to preseed autoconf with a central config.cache with hand-written platform answers once--more convenient than manually patching handwritten makefiles for each package.

I wrote in :

> In a traditional self-hosted build process you can write a program
> that prints the sizeof all the types you care about and then generate
> C code based on that. But in cross-compilation environments, you may
> not have the ability to run code you compile. At some point autoconf
> gained the ability to deduce compile-time constants at by...declaring
> an array of size 1-2*!(expr). If expr is false, the size of the array
> is -1, and the compile fails. autoconf then does a *BINARY SEARCH* of
> the integers for the value....

[1]: Yeah, "testing for broken select() implementation" is not going to work. Sometimes just knowing the target is Linux is good enough for configure to skip those. In more extreme cases you can break out of the config script and hand-run the executable on the target, but I don't remember doing that much.