On 8/21/2017 2:21 AM, Ben Pfaff wrote: > I'm adding the autoconf mailing list. For more background, take a look > at the Debian bug log: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850329 > > On Sun, Aug 20, 2017 at 09:18:44PM +0200, Vincent Lefevre wrote: >> On 2017-08-20 11:01:28 -0700, Ben Pfaff wrote: >>> This bug regards how Autoconf decides whether it's cross-compiling. >>> This is a somewhat tricky issue. The following is summarized from >>> https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Hosts-and-Cross_002dCompilation.html >>> (and quotes come from there): >>> >>> 1. Without --host or --build, Autoconf aborts if it can't run the >>> binaries that the compiler produces. It assumes that's a >>> problem in the system configuration, such as a broken >>> compiler. >>> >>> 2. With --host and --build, Autoconf decides that it's >>> cross-compiling if the host and the build system are >>> different. >>> >>> "If you specify both, and they're different, configure enters >>> cross compilation mode, so it doesn't run any tests that >>> require execution." >>> >>> 3. With --host, but not --build, Autoconf decides that it's >>> cross-compiling if it can't run a binary produced by the >>> compiler: >>> >>> "If you specify --host, but not --build, when configure >>> performs the first compiler test it tries to run an executable >>> produced by the compiler. If the execution fails, it enters >>> cross-compilation mode. This is fragile. Moreover, by the time >>> the compiler test is performed, it may be too late to modify >>> the build-system type: other tests may have already been >>> performed." >>> >>> The issue here is what Autoconf should do in case #3, which is what wine >>> is doing. Is there a better way to detect whether the system can run a >>> binary, than to try to run the binary? Or is there a way to avoid the >>> broken dash behavior? >> >> In case 3, can't Autoconf use the guessed value of BUILD, so that >> it would be like case 2? >> >>> But I am a little concerned about whether we should do anything at all, >>> because case #3 is deprecated: >>> >>> "**Do not rely on [case 3]**, as it will be removed in the near >>> future... Therefore, whenever you specify --host, be sure to >>> specify --build too." >> >> As the --build value can be guessed, I think that it would be annoying >> for the user to force him to use --build in case of cross-compilation. >> IMHO, making case 3 like case 2 with the guessed value of BUILD (as >> I've proposed above) would make sense. That would be the typical case >> for cross-compilation, as in general, one builds on the machine where >> one runs configure. > > Hmm. I'm comfortable with the idea of trying to figure out some way to > avoid trying to execute binaries as if they were shell scripts. On the > other hand, while I don't personally object to changing this basic > Autoconf behavior, this is getting well into the territory where I'd be > uncomfortable proposing it myself. Does anyone on the autoconf mailing > list have thoughts? With --host alone autoconf should assume it is a cross compile without doing any further testing even if the guessed BUILD environment is identical to the specified --host. This would aid in testing the cross build before the package is published. For a native build don't specify --host or specify --build the same as --host. If the specified --build is different from the guessed --build then perhaps a warning but that is questionable as some new system cannot be guessed due to aging config files; maybe make that idea an option to configure that can be specified by the user. -- Earnie _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
