Nick Bowler <nbowler@xxxxxxxxxx> writes: > 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 >>>> is rather hard to follow in general, but also contains the following >>>> clear-cut statement: "Now, configure enters cross-compilation mode if >>>> and only if --host is passed." >>>> >>>> However, if I pass in my build architecture Autoconf 2.69 reports: >>>> >>>> $ ./configure --host=x86_64-linux-gnu >>>> checking for x86_64-linux-gnu-gcc... x86_64-linux-gnu-gcc >>>> checking whether the C compiler works... yes >>>> checking for C compiler default output file name... a.out >>>> checking for suffix of executables... >>>> checking whether we are cross compiling... no >>>> [...] >>>> >>>> That is, it finds the compiler with the prefixed name but does not enter >>>> cross-compilation mode. Does "cross-compilation mode" mean something >>>> different, do I misunderstand the documentation, or what is the >>>> resolution of this apparent (to me) contradiction? >>> >>> I imagine that the authors meant to write "only if", rather than >>> "if and only if" because indeed the statement as written is not true >>> (the manual immediately goes on to explain the actual behaviour). >>> >>> 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. >>> >>> By specifying both --host and --build and then cross compilation mode >>> is enabled whenever they are different. This is the preferred method. >> >> 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..." Hi Nick, Thanks much for your detailed answers and explanations! I noticed that the 2.70 release is being planned, so I recommend to fold all this very useful information into the cross-compilation section of the manual and to drop the out-of-date sentences before the new release is finalized to let your efforts reach wider audience. I haven't added anything below, but left it intact so that this email contains our whole discussion for easier reference. Regards, Feri. >>> 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
