Re: Bug#850329: autoconf tries to execute foreign binaries
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 0xBDA28E02.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Bug#850329: autoconf tries to execute foreign binaries
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@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Bug#850329: autoconf tries to execute foreign binaries
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? ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
