On 2020-08-23, wferi@xxxxxxx <wferi@xxxxxxx> wrote: > Nick Bowler <nbowler@xxxxxxxxxx> writes: >> On 2020-08-22, wferi@xxxxxxx <wferi@xxxxxxx> wrote: >> >>> https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Hosts-and-Cross_002dCompilation.html [...] > The documentation linked above is confusing because it describes the > 2.13 behavior, the 2.50 behavior and the "backward compatibility > scheme" together. For example it starts with "the chain of default is > now simply: target defaults to host, host to build, and build to the > result of config.guess", then later "when --host is specified but > --build isn't, the build system is assumed to be the same as --host", > which is a contradiction, although "eventually, this historically > incorrect behavior will go away." So has this eventuality happened > already? I think either the statement about the build system type being set to the --host value is just wrong or that the eventuality must have happened almost immediately (certainly build_alias does not appear to get set to anything at all if --build is unspecified, contrary to what the manual suggests). The behaviour today is essentially unchanged since the Autoconf 2.50 release almost 2 decades ago. It's quite possible you are the first person to read this section of the manual in all that time and actually say "hey wait a minute..." >> Specifying --host alone *may* select cross compilation based on >> heuristic (whether the compiler's output can be executed). As the >> manual explains this is fragile and is provided for compatibility >> with historical behaviour. > > It also mentions that "by the time the compiler test is performed, it > may be too late to modify the build-system type". What would modify the > build-system type anyway? Isn't this only about whether to enter > cross-compilation mode? I think this is what is meant, since the heuristic is run as part of the compiler detection and any tests run before that in the configure script cannot know whether or not the user is cross compiling. When --build is specified then the cross compilation state does not depend on heuristics and is valid for the entire configure script execution. This may or may not be a real problem in practice. It's hard to imagine a scenario where you would care about the cross compilation state before running the compiler tests. Everything works just fine most of the time if you only specify --host. False positives are a real problem with the heuristic though. E.g., if a system can run the compiled binaries but we are actually cross-building for a different system with different characteristics the heuristic may determine the user is not cross compiling and then runtime tests can give wrong results later. > By the way: does "cross-compilation mode" equal that configure > "doesn't run any tests that require execution", or is this only a > single implication of it? "Cannot run compiled programs" is the primary implication of cross compilation so yes, this primarily affects the behaviour of AC_RUN_IFELSE and configure tests which depend on it. (Any other code you are using can check the cross compilation mode: it is available to configure scripts in the cross_compiling variable). >> By specifying both --host and --build and then cross compilation mode >> is enabled whenever they are different. This is the preferred method. > > I see. But what do I do in a true multiarch setup, for example when I > compile for i386 on an x86_64 build system, which can transparently run > the i386 binaries, and thus I don't want to throw away the tests > requiring execution? Such setups are becoming more and more common. If you are building i386 binaries fully intending for them to be executed on the same machine which is building them then this is not cross compiling. You could either set --host and --build to the same i386-whatever value, which should work fine, or just specify --host alone and configure should correctly determine that you are not cross compiling. Cheers, Nick
