Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1
Hello, On Fri, May 26, 2006 at 07:26:41PM +0200, Ralf Wildenhues wrote: +# ... We should not override ac_cv_exeext if it was +# cached, so that the user can short-circuit this test for compilers +# unknown to Autoconf. ... but it would be better if this override were done by assigning EXEEXT on the configure line, not by assigning ac_cv_exeext. Of course I'm against any change to this fragile code before the release, but I think that the current hack should not be documented. Thus I propose to remove a tiny fraction of Ralf's work, see the attached patch. (I apologize that I haven't noticed it earlier.) Stepan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1
Stepan Kasal [EMAIL PROTECTED] writes: * doc/autoconf.texi (System Services): Do not document overriding EXEEXT via ac_cv_exeext=ext. Thanks, I installed that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1
Hello,
patch forgotten, sorry. Attached to this mail.
Stepan
On Wed, May 31, 2006 at 02:06:53PM +0200, Stepan Kasal wrote:
Hello,
On Fri, May 26, 2006 at 07:26:41PM +0200, Ralf Wildenhues wrote:
+# ... We should not override ac_cv_exeext if it was
+# cached, so that the user can short-circuit this test for compilers
+# unknown to Autoconf.
... but it would be better if this override were done by assigning
EXEEXT on the configure line, not by assigning ac_cv_exeext.
Of course I'm against any change to this fragile code before the
release, but I think that the current hack should not be documented.
Thus I propose to remove a tiny fraction of Ralf's work, see the
attached patch.
(I apologize that I haven't noticed it earlier.)
Stepan
2006-05-31 Stepan Kasal [EMAIL PROTECTED]
* doc/autoconf.texi (System Services): Do not document
overriding EXEEXT via ac_cv_exeext=ext.
Index: doc/autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.1029
diff -u -r1.1029 autoconf.texi
--- doc/autoconf.texi 27 May 2006 22:22:01 - 1.1029
+++ doc/autoconf.texi 31 May 2006 11:32:05 -
@@ -5920,9 +5920,7 @@
All the tests for compilers (@code{AC_PROG_CC}, @code{AC_PROG_CXX},
@code{AC_PROG_F77}) define the output variable @code{EXEEXT} based on
the output of the compiler, typically to the empty string if
-Posix and @samp{.exe} if a @acronym{DOS} variant. It can be overridden
-by passing the argument @[EMAIL PROTECTED] to
[EMAIL PROTECTED]
+Posix and @samp{.exe} if a @acronym{DOS} variant.
@ovindex OBJEXT
They also define the output variable @code{OBJEXT} based on the
Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1
Ralf Wildenhues [EMAIL PROTECTED] writes: Sure. The first patch is the exeext-reversal.diff here: http://lists.gnu.org/archive/html/autoconf-patches/2006-05/msg00090.html and the second patch is the exeext-postreversal2.diff here: http://lists.gnu.org/archive/html/autoconf-patches/2006-05/msg00113.html Sounds good to me; thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1
Hi Eric, Paul, * Eric Blake wrote on Thu, May 25, 2006 at 02:49:17PM CEST: According to Ralf Wildenhues on 5/25/2006 4:49 AM: +# in a Makefile. Because we should not override ac_cv_exeext if it was +# cached, so that the user can short-circuit this test for compilers +# unknown to Autoconf. That last sentence needs help. I would s/Because we/We/. Yep. I did that change... * Paul Eggert wrote on Fri, May 26, 2006 at 07:01:13PM CEST: Sounds good to me; thanks. ...and installed. Thanks for the reviews! Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1
* Ralf Wildenhues wrote on Tue, May 23, 2006 at 11:05:53AM CEST:
* lib/autoconf/lang.m4 (_AC_COMPILER_EXEEXT_DEFAULT): Drop the
initialization of `ac_cv_exeext', do not override it if it was
already set. Add comment about this potential backward
incompatibility. Do not export `ac_cv_exeext', Libtool hasn't
needed this for years.
Scratch this patch. It's Autoconf-2.13 that sets ac_cv_exeext=no.
Next try. OK to commit first the reversal patch posted in an earlier
message, then this one?
Cheers,
Ralf
2006-05-25 Stepan Kasal [EMAIL PROTECTED]
and Ralf Wildenhues [EMAIL PROTECTED]
* lib/autoconf/lang.m4 (_AC_COMPILER_EXEEXT_DEFAULT): Drop the
initialization of `ac_cv_exeext', do not override it if it was
already set, unless it was set to `no', for compatibility with
Autoconf-2.13, and comment this.
Do not export `ac_cv_exeext', Libtool hasn't needed this for years.
(_AC_COMPILER_EXEEXT_DEFAULT): Likewise, do not export it.
(_AC_COMPILER_EXEEXT_WORKS, _AC_COMPILER_EXEEXT_CROSS): Typos.
* doc/autoconf.texi (Compilers and Preprocessors) EXEEXT:
Document that this test may be overridden by setting
`ac_cv_exeext'.
--- lib/autoconf/lang.m42006-05-25 12:45:55.0 +0200
+++ lib/autoconf/lang.m42006-05-25 12:42:36.0 +0200
@@ -495,9 +495,11 @@
rm -f $ac_rmfiles
AS_IF([AC_TRY_EVAL(ac_link_default)],
-[# Be careful to initialize this variable, since it used to be cached.
-# Otherwise an old cache value of `no' led to `EXEEXT = no' in a Makefile.
-ac_cv_exeext=
+[# Autoconf-2.13 could set the ac_cv_exeext variable to `no'.
+# So ignore a value of `no', otherwise this would lead to `EXEEXT = no'
+# in a Makefile. Because we should not override ac_cv_exeext if it was
+# cached, so that the user can short-circuit this test for compilers
+# unknown to Autoconf.
for ac_file in $ac_files
do
test -f $ac_file || continue
@@ -509,16 +511,22 @@
# certainly right.
break;;
*.* )
- ac_cv_exeext=`expr $ac_file : ['[^.]*\(\..*\)']`
- # FIXME: I believe we export ac_cv_exeext for Libtool,
- # but it would be cool to find out if it's true. Does anybody
- # maintain Libtool? --akim.
- export ac_cv_exeext
+if test ${ac_cv_exeext+set} = set test $ac_cv_exeext != no;
+ then :; else
+ ac_cv_exeext=`expr $ac_file : ['[^.]*\(\..*\)']`
+ fi
+ # We set ac_cv_exeext here because the later test for it is not
+ # safe: cross compilers may not add the suffix if given an `-o'
+ # argument, so we may need to know it at that point already.
+ # Even if this section looks crufty: it has the advantage of
+ # actually working.
break;;
* )
break;;
esac
-done],
+done
+test $ac_cv_exeext = no ac_cv_exeext=
+],
[_AC_MSG_LOG_CONFTEST
AC_MSG_FAILURE([_AC_LANG compiler cannot create executables], 77)])
ac_exeext=$ac_cv_exeext
@@ -529,7 +537,7 @@
# _AC_COMPILER_EXEEXT_WORKS
# -
m4_define([_AC_COMPILER_EXEEXT_WORKS],
-[# Check the compiler produces executables we can run. If not, either
+[# Check that the compiler produces executables we can run. If not, either
# the compiler is broken, or we cross compile.
AC_MSG_CHECKING([whether the _AC_LANG compiler works])
# FIXME: These cross compiler hacks should be removed for Autoconf 3.0
@@ -553,7 +561,7 @@
# _AC_COMPILER_EXEEXT_CROSS
# -
m4_define([_AC_COMPILER_EXEEXT_CROSS],
-[# Check the compiler produces executables we can run. If not, either
+[# Check that the compiler produces executables we can run. If not, either
# the compiler is broken, or we cross compile.
AC_MSG_CHECKING([whether we are cross compiling])
AC_MSG_RESULT([$cross_compiling])
@@ -576,7 +584,6 @@
case $ac_file in
_AC_COMPILER_EXEEXT_REJECT ) ;;
*.* ) ac_cv_exeext=`expr $ac_file : ['[^.]*\(\..*\)']`
- export ac_cv_exeext
break;;
* ) break;;
esac
Index: doc/autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.1023
diff -u -r1.1023 autoconf.texi
--- doc/autoconf.texi 25 May 2006 08:49:02 - 1.1023
+++ doc/autoconf.texi 25 May 2006 10:46:59 -
@@ -5911,7 +5911,9 @@
All the tests for compilers (@code{AC_PROG_CC}, @code{AC_PROG_CXX},
@code{AC_PROG_F77}) define the output variable @code{EXEEXT} based on
the output of the compiler, typically to the empty string if
-Posix and @samp{.exe} if a @acronym{DOS} variant.
+Posix and @samp{.exe} if a @acronym{DOS} variant. It can be overridden
+by passing the argument @[EMAIL PROTECTED] to
[EMAIL PROTECTED]
@ovindex OBJEXT
They also define the output variable @code{OBJEXT} based on the
Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ralf, According to Ralf Wildenhues on 5/25/2006 4:49 AM: 2006-05-25 Stepan Kasal [EMAIL PROTECTED] and Ralf Wildenhues [EMAIL PROTECTED] * lib/autoconf/lang.m4 (_AC_COMPILER_EXEEXT_DEFAULT): Drop the initialization of `ac_cv_exeext', do not override it if it was already set, unless it was set to `no', for compatibility with Autoconf-2.13, and comment this. Do not export `ac_cv_exeext', Libtool hasn't needed this for years. (_AC_COMPILER_EXEEXT_DEFAULT): Likewise, do not export it. (_AC_COMPILER_EXEEXT_WORKS, _AC_COMPILER_EXEEXT_CROSS): Typos. * doc/autoconf.texi (Compilers and Preprocessors) EXEEXT: Document that this test may be overridden by setting `ac_cv_exeext'. --- lib/autoconf/lang.m4 2006-05-25 12:45:55.0 +0200 +++ lib/autoconf/lang.m4 2006-05-25 12:42:36.0 +0200 @@ -495,9 +495,11 @@ rm -f $ac_rmfiles AS_IF([AC_TRY_EVAL(ac_link_default)], -[# Be careful to initialize this variable, since it used to be cached. -# Otherwise an old cache value of `no' led to `EXEEXT = no' in a Makefile. -ac_cv_exeext= +[# Autoconf-2.13 could set the ac_cv_exeext variable to `no'. +# So ignore a value of `no', otherwise this would lead to `EXEEXT = no' +# in a Makefile. Because we should not override ac_cv_exeext if it was +# cached, so that the user can short-circuit this test for compilers +# unknown to Autoconf. That last sentence needs help. I would s/Because we/We/. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEdafM84KuGfSFAYARAoCrAJ94cgrU6rkY9hhLBQpzRhuuE5r+ugCePY88 q2+QLeE7L5KMlJWy7NgMARs= =zMV6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1
Ralf Wildenhues [EMAIL PROTECTED] writes: OK to commit first the reversal patch posted in an earlier message, then this one? Sorry, I've lost context. Can you please give us a single message that contains both patches, or a URL to both patches? Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1
Hi Paul, * Paul Eggert wrote on Fri, May 26, 2006 at 12:04:40AM CEST: Ralf Wildenhues [EMAIL PROTECTED] writes: OK to commit first the reversal patch posted in an earlier message, then this one? Sorry, I've lost context. Can you please give us a single message that contains both patches, or a URL to both patches? Thanks. Sure. The first patch is the exeext-reversal.diff here: http://lists.gnu.org/archive/html/autoconf-patches/2006-05/msg00090.html and the second patch is the exeext-postreversal2.diff here: http://lists.gnu.org/archive/html/autoconf-patches/2006-05/msg00113.html Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1
* lib/autoconf/lang.m4 (_AC_COMPILER_EXEEXT_DEFAULT): Drop the initialization of `ac_cv_exeext', do not override it if it was already set. Add comment about this potential backward incompatibility. Do not export `ac_cv_exeext', Libtool hasn't needed this for years. Scratch this patch. It's Autoconf-2.13 that sets ac_cv_exeext=no. If GCC is going to use 2.13 and 2.60 in one tree, then we need to explicitly ignore a cache value of `no'. I'll make another patch. Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1
* Stepan Kasal wrote on Sat, May 20, 2006 at 04:08:38PM CEST: Ralf Wildenhues [EMAIL PROTECTED] writes: I'm still wondering whether we should just simply revert both patches, I have talked with Ralf by phone, and I agree with him that backing out my cleanup (plus later fixes to it) and replacing it by a couple of straightforward fixes for the known issues is the most safe option. ...and here's a hopefully-complete writeup of that: Stepan's patch[1] addressed some issues: - The computation of the executable suffix (EXEEXT/ac_cv_exeext) was not properly overridable by the user. This is a real problem when you want to get a package to work with a compiler Autoconf doesn't know about[2,3]. OTOH, the old semantics were implemented for a reason: # Be careful to initialize this variable, since it used to be cached. # Otherwise an old cache value of `no' led to `EXEEXT = no' in a Makefile. - Removed some outdated comment about a connection to Libtool, that was also questioning whether Libtool is maintained (which is outdated, too :) - Some typo fixes. - The macros needed some cleanup. This can safely be postponed to some time early in a release cycle. Unfortunately, the patch introduced regressions: - The typo Eric found and was fixed a couple of days later (in the same thread). - The issue that prompted this thread, namely: It does not suffice to look for a compiler extension with $CC -o conftest conftest.$ac_ext Why? For example, on Cygwin or MinGW, the compiler will create the file conftest.exe. There, we will be fine: we do make sure to not get fooled by the Cygwin file testing features. But with a cross-compiler GNU/Linux - MinGW the above line will simply create the file conftest. This isn't what we want though: the executable should be transferable to a MinGW system without renaming. So, we have to also make use of what the compiler creates by default, with $CC conftest.$ac_ext which will be a.exe. So, I propose to undo Stepan's and Eric's patch (see first attachment), fix the comment and the typos, address the old caching semantics in a new comment, and fix the caching issue. I also propose to document the overridability now (though I'm not sure whether that is ok), all in the second attachment. What do you think? Cheers, Ralf [1] http://lists.gnu.org/archive/html/autoconf-patches/2006-04/msg00027.html [2] http://lists.gnu.org/archive/html/autoconf/2006-05/msg00071.html [3] http://lists.gnu.org/archive/html/autoconf/2005-11/msg00033.html 2006-05-22 Ralf Wildenhues [EMAIL PROTECTED] Revert these two patches: 2006-04-06 Eric Blake [EMAIL PROTECTED] * lib/autoconf/lang.m4 (_AC_COMPILER_EXEEXT_O): Inside cache check, s/ac_exeext/ac_cv_exeext/. Fixes regression introduced 2006-04-01. 2006-04-01 Stepan Kasal [EMAIL PROTECTED] Clean up _AC_COMPILER_EXEEXT* macros. * lib/autoconf/lang.m4 (_AC_COMPILER_EXEEXT_DEFAULT): Don't try to detect exeext, it will be done by _AC_COMPILER_EXEEXT_O; just set ac_file to the name of the default output file and call _AC_COMPILER_EXEEXT_WORKS. Move the definition of ac_files and the initial `rm' of the candidate files... (_AC_COMPILER_EXEEXT): ... here and simplify them. Moreover, use the same list in subsequent `rm' calls, and for the temporary redefinition of ac_clean_files; call _AC_COMPILER_OBJEXT at the end, and don't call the other _AC_COMPILER_EXEEXT_* macros directly, use... (_AC_COMPILER_EXEEXT_TESTS): ... this new macro. (_AC_COMPILER_EXEEXT_O): Don't export ac_cv_exeext, it's not needed (or no longer needed) by libtool. Make it a cache check. (_AC_COMPILER_EXEEXT_CROSS): Remove the comment, it was obviously copied here by mistake. (AC_NO_EXECUTABLES): Redefine _AC_COMPILER_EXEEXT_TESTS, not _AC_COMPILER_EXEEXT. * lib/autoconf/c.m4 (AC_PROG_CC, AC_PROG_CXX, AC_PROG_OBJC): Do not call _AC_COMPILER_OBJEXT directly. * lib/autoconf/fortran.m4 (_AC_PROG_FC): Likewise. Index: lib/autoconf/c.m4 === RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/c.m4,v retrieving revision 1.226 diff -u -r1.226 c.m4 --- lib/autoconf/c.m4 20 May 2006 15:49:27 - 1.226 +++ lib/autoconf/c.m4 22 May 2006 18:32:47 - @@ -548,6 +548,7 @@ _AC_EVAL([$ac_compiler -V AS_MESSAGE_LOG_FD]) m4_expand_once([_AC_COMPILER_EXEEXT])[]dnl +m4_expand_once([_AC_COMPILER_OBJEXT])[]dnl _AC_LANG_COMPILER_GNU GCC=`test $ac_compiler_gnu = yes echo yes` _AC_PROG_CC_G @@ -775,6 +776,7 @@ _AC_EVAL([$ac_compiler -V AS_MESSAGE_LOG_FD]) m4_expand_once([_AC_COMPILER_EXEEXT])[]dnl +m4_expand_once([_AC_COMPILER_OBJEXT])[]dnl _AC_LANG_COMPILER_GNU GXX=`test $ac_compiler_gnu = yes echo yes` _AC_PROG_CXX_G @@
Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1
Hello, Ralf Wildenhues [EMAIL PROTECTED] writes: I'm still wondering whether we should just simply revert both patches, I have talked with Ralf by phone, and I agree with him that backing out my cleanup (plus later fixes to it) and replacing it by a couple of straightforward fixes for the known issues is the most safe option. Thank you, Ralf, that you analysed this, explained it to me, and that you will implement it. ;-) Gratefully, Stepan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1
Package: autoconf Version: 2.59.cvs.2006.05.13-1 Severity: important If crosscompiling an autotools based package with mingw for Windows using this autoconf version, the resulting executable misses the .exe extension. Going back to autoconf-2.59a-9 solves the problem. Steps to reproduce: - install the following additional packages: mingw32, automake1.9 - Get a minimal autoconf/automake based project from http://filezilla-project.org/codesquid/hello.tar.bz2 - Execute the following commands: tar -xjf hello.tar.bz2 cd hello aclocal autoconf automake -a ./configure --host=i586-mingw32msvc --target=i496-mingw32msvc make Expected results: hello.exe Actual results: hello -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27-1-386 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages autoconf depends on: ii debianutils 2.16 Miscellaneous utilities specific t ii m41.4.4-1a macro processing language ii perl 5.8.8-4Larry Wall's Practical Extraction Versions of packages autoconf recommends: ii automake1.9 [automaken] 1.9.6-4A tool for generating GNU Standard -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1
Tim Kosse [EMAIL PROTECTED] writes: ./configure --host=i586-mingw32msvc --target=i496-mingw32msvc Does it have the same behavior without the typo (496 - 486)? -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Pfaff wrote: Tim Kosse [EMAIL PROTECTED] writes: ./configure --host=i586-mingw32msvc --target=i496-mingw32msvc Does it have the same behavior without the typo (496 - 486)? Sorry for the typo, the line should have been ./configure - --host=i586-mingw32msvc --target=i586-mingw32msvc To be sure I've tried again with both the correct as well as the incorrect command, result is the same in both cases. The compiled executable is 'hello' which is a valid windows executable. Just the extension is missing. $ file hello hello: MS-DOS executable PE for MS Windows (console) Intel 80386 32-bit Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEbeuq8N9+lcqiUkURAgmYAJ4xzfOLRYr3+8vWZaPRBWSIWi+gSQCgiuez zJxkiEDRuW3wNmTAGvxXFqo= =mygV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1
Tim Kosse [EMAIL PROTECTED] writes: Ben Pfaff wrote: Tim Kosse [EMAIL PROTECTED] writes: ./configure --host=i586-mingw32msvc --target=i496-mingw32msvc Does it have the same behavior without the typo (496 - 486)? Sorry for the typo, the line should have been ./configure --host=i586-mingw32msvc --target=i586-mingw32msvc To be sure I've tried again with both the correct as well as the incorrect command, result is the same in both cases. The compiled executable is 'hello' which is a valid windows executable. Just the extension is missing. OK. I'll take a look. I just wanted to make sure it was a transcription error, not a fundamental mistake. -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1
[ Cc:ing bug-autoconf as this is a genuine bug IMHO. ] Hi Tim, Thanks for reporting this! * Tim Kosse wrote on Fri, May 19, 2006 at 10:56:01AM CEST: Package: autoconf Version: 2.59.cvs.2006.05.13-1 Severity: important If crosscompiling an autotools based package with mingw for Windows using this autoconf version, the resulting executable misses the .exe extension. Going back to autoconf-2.59a-9 solves the problem. Steps to reproduce: - install the following additional packages: mingw32, automake1.9 - Get a minimal autoconf/automake based project from http://filezilla-project.org/codesquid/hello.tar.bz2 - Execute the following commands: tar -xjf hello.tar.bz2 cd hello aclocal autoconf automake -a ./configure --host=i586-mingw32msvc --target=i496-mingw32msvc make Expected results: hello.exe Actual results: hello Confirmed. The cleanup patch http://lists.gnu.org/archive/html/autoconf-patches/2006-04/msg00027.html (there's been one fix to it in the same thread) broke this. I'm still wondering whether we should just simply revert both patches, and then turn | # FIXME: I believe we export ac_cv_exeext for Libtool, | # but it would be cool to find out if it's true. Does anybody | # maintain Libtool? --akim. into | # We export ac_cv_exeext here because the latter test is not | # safe: cross compilers may not add the suffix if given an `-o' | # argument, so we may need to know it at that point already. | # Even if this section looks crufty: it has the advantage of | # actually working. and leave a cleanup of this section to the beginning of a development cycle of Autoconf, not to an end of it. Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1
Re http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=368012, Ralf Wildenhues [EMAIL PROTECTED] writes: http://lists.gnu.org/archive/html/autoconf-patches/2006-04/msg00027.html ... broke this. I'm still wondering whether we should just simply revert both patches, ... and leave a cleanup of this section to the beginning of a development cycle of Autoconf, not to an end of it. Stepan, what do you think? If we can't fix the bug in fairly short order I'm inclined to agree with Ralf. I don't have time to look into it myself right now, unfortunately. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
