On 21/08/17 07:21, Ben Pfaff wrote: >> 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? As a MinGW.org developer who uses LinuxMint Debian Edition as my primary development platform, I've certainly found this autoconf behaviour to be annoying, for some considerable time; (this annoyance is compounded by config.sub, which forces me to specify the fully qualified build triplet, for any project which uses AC_CANONICAL_SYSTEM, or even just AC_CANONICAL_BUILD). Nonetheless, I do always specify both --build and --host, because of the ambiguity introduced by specifying --host alone). While I agree that this is an annoying (mis)feature of autoconf design, as I see it, the ambiguity is triggered, not by any feature of whichever shell is employed, but by the Linux kernel's own miscellaneous binaries (binfmt_misc) support, which allows Windows binaries to be executed via wine, providing it is installed, without it being explicitly specified: $ uname -a Linux ... 3.11-2-amd64 #1 SMP Debian 3.11.8-1 (2013-11-13) x86_64 GNU/Linux $ file dist/staged/bin/gcc.exe dist/staged/bin/gcc.exe: PE32 executable (console) Intel 80386 (stripped to external PDB), for MS Windows $ dist/staged/bin/gcc.exe --version gcc.exe (MinGW.org GCC-6.3.0-1) 6.3.0 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Regards, Keith
Attachment:
0xBDA28E02.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
