bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Building 32 bit Emacs `master' on MSYS2 64 bits on a Windows 64 bit host
creates an invalid temacs.exe.

What follows is the analysis made by an MSYS2 user (David Macek) on the
MSYS2 mailing list:

Few notes first. Running the binary directly from Windows shell causes
appinfo to display an "app can't run on your PC" error, which is
common for architecture mismatches (like when running x64 binary on
x86 system). Running "strace ./temacs" confirmed it by displaying
error code 193 (ERROR_BAD_EXE_FORMAT, "... is not a valid Win32
application").

The command that links temacs.exe on i686:

> gcc -std=gnu99 -Demacs -I. -I. -I../lib -I../lib -mtune=generic
> -pthread -mms-bitfields
> -ID:/applications/msys2.x64/mingw32/include/librsvg-2.0
> -ID:/applications/msys2.x64/mingw32/include/gdk-pixbuf-2.0
> -ID:/applications/msys2.x64/mingw32/include/libpng16
> -ID:/applications/msys2.x64/mingw32/include/cairo
> -ID:/applications/msys2.x64/mingw32/include/glib-2.0
> -ID:/applications/msys2.x64/mingw32/lib/glib-2.0/include
> -ID:/applications/msys2.x64/mingw32/include/pixman-1
> -ID:/applications/msys2.x64/mingw32/include -I/mingw32/include
> -I/mingw32/include/freetype2 -I/mingw32/include
> -I/mingw32/include/libpng16 -I/mingw32/include/harfbuzz
> -ID:/applications/msys2.x64/mingw32/include
> -ID:/applications/msys2.x64/mingw32/include/freetype2
> -ID:/applications/msys2.x64/mingw32/include
> -ID:/applications/msys2.x64/mingw32/include/harfbuzz
> -ID:/applications/msys2.x64/mingw32/include/libpng16 -fopenmp
> -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 -D_DLL
> -D_MT -fopenmp -DMAGICKCORE_HDR
I_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 -D_DLL -D_MT
-ID:/applications/msys2.x64/mingw32/include/ImageMagick-6
-ID:/applications/msys2.x64/mingw32/include/libxml2
-ID:/applications/msys2.x64/mingw32/include/dbus-1.0
-ID:/applications/msys2.x64/mingw32/lib/dbus-1.0/include -MMD -MF
deps/.d -MP -ID:/applications/msys2.x64/mingw32/include
-ID:/applications/msys2.x64/mingw32/include/p11-kit-1
-ID:/applications/msys2.x64/mingw32/include -g3 -O2 -gdwarf-2
-Wl,-stack,0x00800000 -Wl,-heap,0x00100000 -Wl,-image-base,0x400000000
-Wl,-entry,__start -Wl,-Map,./temacs.map -o temacs firstfile.o
dispnew.o frame.o scroll.o xdisp.o menu.o window.o charset.o coding.o
category.o ccl.o character.o chartab.o bidi.o term.o terminal.o
xfaces.o dbusbind.o emacs.o keyboard.o macros.o keymap.o sysdep.o
buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o
cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o
data.o doc.o editfns.o callint.o eval.o floatfns.o
fns.o font.o print.o lread.o syntax.o unexw32.o bytecode.o process.o
gnutls.o callproc.o region-cache.o sound.o atimer.o doprnt.o
intervals.o textprop.o composite.o xml.o w32notify.o profiler.o
decompress.o w32fns.o w32menu.o w32reg.o w32font.o w32term.o w32xfns.o
w32select.o w32uniscribe.o w32.o w32console.o w32heap.o w32inevt.o
w32proc.o fontset.o fringe.o image.o tparam.o lastfile.o
../lib/libgnu.a emacs.res -lwinmm -lgdi32 -lcomdlg32 -lmpr -lwinspool
-lole32 -lcomctl32 -lusp10 -LD:/applications/msys2.x64/mingw32/lib
-lMagickWand-6.Q16HDRI -lMagickCore-6.Q16HDRI
-LD:/applications/msys2.x64/mingw32/lib -ldbus-1

The offending argument is "-Wl,-image-base,0x400000000", which sets
the executable to instruct Windows loader to load the executable at
the 16 GiB mark or higher in virtual memory, which is ridiculous for a
32-bit program. So although the error message is not very clear, it's
justified, this binary can't be loaded.

I found the declaration in configure.ac in a case starting at line
4911. The linker argument is added there when building on 64-bit
mingw, probably in an attempt to improve performance and/or
compatibility. The problem is that even on i686, the $canonical
triplet is "x86_64-pc-mingw32". I have not tried to find out why the
triplet is wrong. The PKGBUILD doesn't have this problem because it
always passes correct "--build=${MINGW_CHOST}" to configure.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Eli Zaretskii]

> From: ofv@wanadoo.es (Óscar Fuentes)
> Date: Wed, 19 Nov 2014 21:27:50 +0100
> 
> The offending argument is "-Wl,-image-base,0x400000000", which sets
> the executable to instruct Windows loader to load the executable at
> the 16 GiB mark or higher in virtual memory, which is ridiculous for a
> 32-bit program. So although the error message is not very clear, it's
> justified, this binary can't be loaded.
> 
> I found the declaration in configure.ac in a case starting at line
> 4911. The linker argument is added there when building on 64-bit
> mingw, probably in an attempt to improve performance and/or
> compatibility.

No, the goal is to find bugs with bad pointers faster: higher
addresses are more likely to segfault when they are bogus.

> The problem is that even on i686, the $canonical triplet is
> "x86_64-pc-mingw32". I have not tried to find out why the triplet is
> wrong.

I'm guessing this is a MSYS2 problem, since uname is an MSYS2 program,
and it doesn't know you are going to build a 32-bit build.  Can you
try with an explicit --host or --build argument?

> The PKGBUILD doesn't have this problem because it always passes
> correct "--build=${MINGW_CHOST}" to configure.

Not sure what PKGBUILD is and what is MINGW_CHOST it uses, or why.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> The problem is that even on i686, the $canonical triplet is
>> "x86_64-pc-mingw32". I have not tried to find out why the triplet is
>> wrong.
>
> I'm guessing this is a MSYS2 problem, since uname is an MSYS2 program,
> and it doesn't know you are going to build a 32-bit build.  Can you
> try with an explicit --host or --build argument?

It works. See below.

>> The PKGBUILD doesn't have this problem because it always passes
>> correct "--build=${MINGW_CHOST}" to configure.
>
> Not sure what PKGBUILD is and what is MINGW_CHOST it uses, or why.

PKGBUILD is a build recipe used for building a software package in MSYS2
(and Arch Linux). The PKGBUILD used for building Emacs sets --build and
--host on the configure script. When building the binary package,
MINGW_CHOST is i686-w64-mingw32.

The problem here is that, without explicitly setting --host/--build,
uname is not the right thing for detecting the host/build environment,
because uname is a MSYS2 thing, when we are building with a MinGW
toolset. So either we stop using uname for MinGW builds (use $MSYSTEM),
or document that --host/--build are required.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

> The problem here is that, without explicitly setting --host/--build,
> uname is not the right thing for detecting the host/build environment,
> because uname is a MSYS2 thing, when we are building with a MinGW
> toolset. So either we stop using uname for MinGW builds (use $MSYSTEM),
> or document that --host/--build are required.

There other places on `configure' that uses the contents of $canonical
for deciding if its creating an 32 or 64 bits MinGW build.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

> There other places on `configure' that uses the contents of $canonical
> for deciding if its creating an 32 or 64 bits MinGW build.

Opinions?

diff --git a/configure.ac b/configure.ac
index 5d71c2f..f286246 100644
--- a/configure.ac
+++ b/configure.ac
@@ -665,8 +665,8 @@ case "${canonical}" in
 
   # MinGW64
   x86_64-*-* )
-    case "${canonical}" in
-      *-mingw* )
+    case "${MSYSTEM}" in
+      MINGW64 )
 		opsys=mingw32
 		# MinGW overrides and adds some system headers in nt/inc.
 		GCC_TEST_OPTIONS="-I $srcdir/nt/inc"
@@ -1331,8 +1331,8 @@ C_SWITCH_SYSTEM=
 test "$opsys" = "aix4.2" && test "x$GCC" != "xyes" && \
   C_SWITCH_SYSTEM="-ma -qmaxmem=4000"
 if test "$opsys" = "mingw32"; then
-  case "$canonical" in
-    x86_64-*-mingw*) C_SWITCH_SYSTEM="-mtune=generic" ;;
+  case "$MSYSTEM" in
+    MINGW64) C_SWITCH_SYSTEM="-mtune=generic" ;;
     *) C_SWITCH_SYSTEM="-mtune=pentium4" ;;
   esac
 fi
@@ -1881,8 +1881,8 @@ if test "${HAVE_W32}" = "yes"; then
   W32_OBJ="w32fns.o w32menu.o w32reg.o w32font.o w32term.o"
   W32_OBJ="$W32_OBJ w32xfns.o w32select.o w32uniscribe.o"
   EMACSRES="emacs.res"
-  case "$canonical" in
-    x86_64-*-*) EMACS_MANIFEST="emacs-x64.manifest" ;;
+  case "$MSYSTEM" in
+    MINGW64) EMACS_MANIFEST="emacs-x64.manifest" ;;
     *) EMACS_MANIFEST="emacs-x86.manifest" ;;
   esac
   if test "${opsys}" = "cygwin"; then
@@ -4908,8 +4908,8 @@ case "$opsys" in
 
   mingw32)
    ## Is it any better under MinGW64 to relocate emacs into higher addresses?
-   case "$canonical" in
-     x86_64-*-*) LD_SWITCH_SYSTEM_TEMACS="-Wl,-stack,0x00800000 -Wl,-heap,0x00100000 -Wl,-image-base,0x400000000 -Wl,-entry,__start -Wl,-Map,./temacs.map" ;;
+   case "$MSYSTEM" in
+     MINGW64) LD_SWITCH_SYSTEM_TEMACS="-Wl,-stack,0x00800000 -Wl,-heap,0x00100000 -Wl,-image-base,0x400000000 -Wl,-entry,__start -Wl,-Map,./temacs.map" ;;
      *) LD_SWITCH_SYSTEM_TEMACS="-Wl,-stack,0x00800000 -Wl,-heap,0x00100000 -Wl,-image-base,0x01000000 -Wl,-entry,__start -Wl,-Map,./temacs.map" ;;
    esac
    ;;

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: 19111@debbugs.gnu.org
> Date: Wed, 19 Nov 2014 23:01:44 +0100
> 
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
> > There other places on `configure' that uses the contents of $canonical
> > for deciding if its creating an 32 or 64 bits MinGW build.
> 
> Opinions?
> 
> diff --git a/configure.ac b/configure.ac
> index 5d71c2f..f286246 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -665,8 +665,8 @@ case "${canonical}" in
>  
>    # MinGW64
>    x86_64-*-* )
> -    case "${canonical}" in
> -      *-mingw* )
> +    case "${MSYSTEM}" in
> +      MINGW64 )
>  		opsys=mingw32

I don't want to special-case MinGW builds like that.  The whole point
of using MSYS was to bring the Windows builds as close to Posix ones
as possible.

As I wrote elsewhere, using --hos/--build in the rare case we are
discussing should be "good enough", if we document it.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: 19111@debbugs.gnu.org
> Date: Wed, 19 Nov 2014 22:50:32 +0100
> 
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
> > The problem here is that, without explicitly setting --host/--build,
> > uname is not the right thing for detecting the host/build environment,
> > because uname is a MSYS2 thing, when we are building with a MinGW
> > toolset. So either we stop using uname for MinGW builds (use $MSYSTEM),
> > or document that --host/--build are required.
> 
> There other places on `configure' that uses the contents of $canonical
> for deciding if its creating an 32 or 64 bits MinGW build.

I think that's correct.  $canonical should have the right value, as it
does on other platforms.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: 19111@debbugs.gnu.org
> Date: Wed, 19 Nov 2014 22:27:30 +0100
> 
> The problem here is that, without explicitly setting --host/--build,
> uname is not the right thing for detecting the host/build environment,
> because uname is a MSYS2 thing, when we are building with a MinGW
> toolset. So either we stop using uname for MinGW builds (use $MSYSTEM),
> or document that --host/--build are required.

When you use MinGW64 for building a 32-bit executable, you are in
effect cross-compiling.  So I think telling users to use an explicit
"--host/--build" argument is TRT, especially since I don't envision
many people doing that, except for special-case testing.

Patches for nt/INSTALL are welcome.

Thanks.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Cc: 19111@debbugs.gnu.org
>> Date: Wed, 19 Nov 2014 22:27:30 +0100
>> 
>> The problem here is that, without explicitly setting --host/--build,
>> uname is not the right thing for detecting the host/build environment,
>> because uname is a MSYS2 thing, when we are building with a MinGW
>> toolset. So either we stop using uname for MinGW builds (use $MSYSTEM),
>> or document that --host/--build are required.
>
> When you use MinGW64 for building a 32-bit executable, you are in
> effect cross-compiling.  So I think telling users to use an explicit
> "--host/--build" argument is TRT, especially since I don't envision
> many people doing that, except for special-case testing.

When we use the mingw toolset under MSYS{2} we are cross-compiling, as
far as autoconf is concerned. But truth is that Emacs' `configure.ac'
already special-cases MinGW by using $MSYSTEM and not requiring
--host/--build, to hide the cross-compilation and make user's life
simple.

Such special handling of the MSYS/MinGW combo assumes that the target
architecture of the MinGW toolset being used is the same as the MSYS
architecture retrieved by `uname'. Once we have MSYS2 supporting both
i686 and x86_64, and MinGW-w64 also supporting both architectures, the
assumption is broken. I foresee similar problems when building for
MINGW64 on a i686 MSYS2.

> Patches for nt/INSTALL are welcome.

Since we already special-case MinGW on the configure script, and fixing
the problem there only changes how the special case is implemented
without touching new areas, I'll very much prefer to apply the patch
shown on my previous message and keep the nice and simple "configure &&
make" procedure working on all cases.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: 19111@debbugs.gnu.org
> Date: Thu, 20 Nov 2014 05:10:06 +0100
> 
> When we use the mingw toolset under MSYS{2} we are cross-compiling, as
> far as autoconf is concerned. But truth is that Emacs' `configure.ac'
> already special-cases MinGW by using $MSYSTEM and not requiring
> --host/--build, to hide the cross-compilation and make user's life
> simple.
> 
> Such special handling of the MSYS/MinGW combo assumes that the target
> architecture of the MinGW toolset being used is the same as the MSYS
> architecture retrieved by `uname'.

Yes, but it worked until now.  It's a fragile situation, I agree, but
the whole MSYS thing is fragile anyway.  IMO, we are lucky that it
works so well.

> Once we have MSYS2 supporting both i686 and x86_64, and MinGW-w64
> also supporting both architectures, the assumption is broken. I
> foresee similar problems when building for MINGW64 on a i686 MSYS2.
> 
> > Patches for nt/INSTALL are welcome.
> 
> Since we already special-case MinGW on the configure script, and fixing
> the problem there only changes how the special case is implemented
> without touching new areas, I'll very much prefer to apply the patch
> shown on my previous message and keep the nice and simple "configure &&
> make" procedure working on all cases.

OK, but at least let's keep the build/host/target triplet correct.
It's not right for us to disregard it when it doesn't fit our needs,
because the entire configure script is based on the notion that the
triplet is the starting point on which all the rest is based.

So, if we want to fix that, let's fix the triplet early on, to specify
a i686 build, and let the rest of the script do its job as usual.

Besides, I came to a conclusion that I don't understand how your
suggestion will work anyway.  AFAICT, you just replace tests based on
one wrong string (x86_64-*-*) with another wrong string (MINGW64).

Or are you saying that MSYS2 somehow magically does not give $MSYSTEM
the value MINGW64 when you configure for a 32-bit build?  If so, how
does this magic work?  Because if MSYS2 always sets MSYSTEM=MINGW64,
then your suggestion isn't going to work, is it?

More generally, how do you tell configure that you want a 32-bit build
using MinGW64 toolchain?  That requires some special compiler switches
(like -m32 or some such), no?

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Since we already special-case MinGW on the configure script, and fixing
>> the problem there only changes how the special case is implemented
>> without touching new areas, I'll very much prefer to apply the patch
>> shown on my previous message and keep the nice and simple "configure &&
>> make" procedure working on all cases.
>
> OK, but at least let's keep the build/host/target triplet correct.
> It's not right for us to disregard it when it doesn't fit our needs,
> because the entire configure script is based on the notion that the
> triplet is the starting point on which all the rest is based.
>
> So, if we want to fix that, let's fix the triplet early on, to specify
> a i686 build, and let the rest of the script do its job as usual.

I suspect that you have a point here which I don't entirely grasp.

Are you thinking on a scenario where the user sets --host/--build on the
configure script to something that doesn't correlate to the contents of
$MSYSTEM?

> Besides, I came to a conclusion that I don't understand how your
> suggestion will work anyway.  AFAICT, you just replace tests based on
> one wrong string (x86_64-*-*) with another wrong string (MINGW64).
>
> Or are you saying that MSYS2 somehow magically does not give $MSYSTEM
> the value MINGW64 when you configure for a 32-bit build?  If so, how
> does this magic work?  Because if MSYS2 always sets MSYSTEM=MINGW64,
> then your suggestion isn't going to work, is it?
>
> More generally, how do you tell configure that you want a 32-bit build
> using MinGW64 toolchain?  That requires some special compiler switches
> (like -m32 or some such), no?

We are using $MSYSTEM to special-case MinGW(-w64). $MSYSTEM is MINGW32
when using the 32 bit toolset and MINGW64 when using the 64 bit toolset.
That's true for MSYS2/MinGW-w64. I'm not sure if MSYS sets $MSYSTEM to
MINGW or MINGW32, but any of it should be ok with the patch.

The -m32 switch is actively discouraged by the MinGW-w64 community and
the official builds does not support it.

Does this answer your questions?

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: 19111@debbugs.gnu.org
> Date: Thu, 20 Nov 2014 17:23:14 +0100
> 
> > OK, but at least let's keep the build/host/target triplet correct.
> > It's not right for us to disregard it when it doesn't fit our needs,
> > because the entire configure script is based on the notion that the
> > triplet is the starting point on which all the rest is based.
> >
> > So, if we want to fix that, let's fix the triplet early on, to specify
> > a i686 build, and let the rest of the script do its job as usual.
> 
> I suspect that you have a point here which I don't entirely grasp.
> 
> Are you thinking on a scenario where the user sets --host/--build on the
> configure script to something that doesn't correlate to the contents of
> $MSYSTEM?

No, I'm trying to follow your suggestion that just "./configure && make"
should DTRT.

> > Besides, I came to a conclusion that I don't understand how your
> > suggestion will work anyway.  AFAICT, you just replace tests based on
> > one wrong string (x86_64-*-*) with another wrong string (MINGW64).
> >
> > Or are you saying that MSYS2 somehow magically does not give $MSYSTEM
> > the value MINGW64 when you configure for a 32-bit build?  If so, how
> > does this magic work?  Because if MSYS2 always sets MSYSTEM=MINGW64,
> > then your suggestion isn't going to work, is it?
> >
> > More generally, how do you tell configure that you want a 32-bit build
> > using MinGW64 toolchain?  That requires some special compiler switches
> > (like -m32 or some such), no?
> 
> We are using $MSYSTEM to special-case MinGW(-w64). $MSYSTEM is MINGW32
> when using the 32 bit toolset and MINGW64 when using the 64 bit toolset.
> That's true for MSYS2/MinGW-w64. I'm not sure if MSYS sets $MSYSTEM to
> MINGW or MINGW32, but any of it should be ok with the patch.
> 
> The -m32 switch is actively discouraged by the MinGW-w64 community and
> the official builds does not support it.
> 
> Does this answer your questions?

Sorry, it doesn't.  You say that $MSYSTEM is set to either MINGW32 or
MINGW64, depending on whether 32-bit or 64-bit toolset is used.  But
how does MSYS2 know which toolset you are going to use to compile a
program?  How do you communicate that to MSYS2?

In any case, what I suggest to do is correct the triplet,
automatically, after uname guesses it, if we find that it is wrong for
"the toolset about to be used", whatever that means.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> We are using $MSYSTEM to special-case MinGW(-w64). $MSYSTEM is MINGW32
>> when using the 32 bit toolset and MINGW64 when using the 64 bit toolset.
>> That's true for MSYS2/MinGW-w64. I'm not sure if MSYS sets $MSYSTEM to
>> MINGW or MINGW32, but any of it should be ok with the patch.
>> 
>> The -m32 switch is actively discouraged by the MinGW-w64 community and
>> the official builds does not support it.
>> 
>> Does this answer your questions?
>
> Sorry, it doesn't.  You say that $MSYSTEM is set to either MINGW32 or
> MINGW64, depending on whether 32-bit or 64-bit toolset is used.  But
> how does MSYS2 know which toolset you are going to use to compile a
> program?  How do you communicate that to MSYS2?

It is set automatically by the .bat file that starts the MSYS2 shell.
There is a .bat that sets $MSYSTEM, paths, etc for MINGW32, other for
MINGW64 and other for MSYS.

In the end, the user must ensure that $MSYSTEM matches the toolset he is
going to use. This is nothing new. The Emacs build fails if $MSYSTEM is
not correctly set, for MinGW(-w64) builds.

> In any case, what I suggest to do is correct the triplet,
> automatically, after uname guesses it, if we find that it is wrong for
> "the toolset about to be used", whatever that means.

How do we know that the triplet is wrong? The easy way is to inspect
$MSYSTEM, but if that's the solution then we could stop using the
triplet altogether and use $MSYSTEM instead (which is what my patch
does.)

Another solution is to get the --host/--build triplet from `gcc -v' (use
the `--target=...' part. I don't know how it is supposed to deal with
the case of the user setting those parameters explicitly, although I
can't think of a valid reason for setting --host/--build to something
different from the `gcc -v' --target, since Emacs does not support
cross-compiling.

I understand your concern: `configure' can use the triplet anywhere and
hence it is important that it is correct.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Dani Moncayo]

(I Just want to point out two things, FWIW)

> In the end, the user must ensure that $MSYSTEM matches the toolset he is
> going to use. This is nothing new. The Emacs build fails if $MSYSTEM is
> not correctly set, for MinGW(-w64) builds.

AFAIK, $MSYSTEM is used in the emacs-24 branch, but not in the trunk.

> Another solution is to get the --host/--build triplet from `gcc -v' (use
> the `--target=...' part. I don't know how it is supposed to deal with
> the case of the user setting those parameters explicitly, although I
> can't think of a valid reason for setting --host/--build to something
> different from the `gcc -v' --target, since Emacs does not support
> cross-compiling.

But perhaps it could support that in the future.  It would be
nice to be able to cross-compile (the MS-Windows native) Emacs
from Cygwin, for example.

-- 
Dani Moncayo

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: 19111@debbugs.gnu.org
> Date: Thu, 20 Nov 2014 19:30:37 +0100
> 
> > Sorry, it doesn't.  You say that $MSYSTEM is set to either MINGW32 or
> > MINGW64, depending on whether 32-bit or 64-bit toolset is used.  But
> > how does MSYS2 know which toolset you are going to use to compile a
> > program?  How do you communicate that to MSYS2?
> 
> It is set automatically by the .bat file that starts the MSYS2 shell.
> There is a .bat that sets $MSYSTEM, paths, etc for MINGW32, other for
> MINGW64 and other for MSYS.

Is that reliable enough?  What if someone does these things by hand,
without relying on batch files?

> In the end, the user must ensure that $MSYSTEM matches the toolset he is
> going to use.

Why?  We don't even use $MSYSTEM in the configure script (on master),
and neither do other GNU packages.

> > In any case, what I suggest to do is correct the triplet,
> > automatically, after uname guesses it, if we find that it is wrong for
> > "the toolset about to be used", whatever that means.
> 
> How do we know that the triplet is wrong?

One way is to run the compiler, I guess.

> Another solution is to get the --host/--build triplet from `gcc -v' (use
> the `--target=...' part.

Yes, something like that.

> I don't know how it is supposed to deal with the case of the user
> setting those parameters explicitly, although I can't think of a
> valid reason for setting --host/--build to something different from
> the `gcc -v' --target, since Emacs does not support cross-compiling.

If the user sets the triplet, it should be obeyed.  If it's incorrect,
that's the user's problem.

> I understand your concern: `configure' can use the triplet anywhere and
> hence it is important that it is correct.

Yes, exactly.

Could you propose a patch along these lines?

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> If the user sets the triplet, it should be obeyed.  If it's incorrect,
> that's the user's problem.
>
>> I understand your concern: `configure' can use the triplet anywhere and
>> hence it is important that it is correct.
>
> Yes, exactly.
>
> Could you propose a patch along these lines?

Something like this, perhaps? (It should also work for Dani's Cygwin
case.)

diff --git a/configure.ac b/configure.ac
index 5d71c2f..8efde0f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -145,6 +145,29 @@ case $canonical in
  *-mingw*)
   . $srcdir/nt/mingw-cfg.site
 
+  # When we build with MinGW under MSYS, we are cross-compiling. Hence
+  # we can't rely on the output of MSYS `uname' for the architecture
+  # (32 bit MinGW compiler with 64 bit MSYS2, for instance) and must use the
+  # compiler's target, unless when the user explicitly provides one:
+  if test -z $target_alias; then
+      AC_MSG_CHECKING([the compiler's target])
+      if test -z $CC; then
+	  cc=gcc
+      else
+	  cc=$CC
+      fi
+      t=$($cc -v 2>&1 | grep "^Target: ")
+      t=${t#Target: }
+      if test "x$t" = "x"; then
+	  AC_MSG_ERROR([Impossible to determine $cc compiler target.
+Please explicitly provide --target])
+      fi
+      canonical=$t
+      AC_MSG_RESULT([$canonical])
+  else
+      canonical=$target_alias
+  fi
+
   case $srcdir in
     /* | ?:*)
       # srcdir is an absolute path.  In this case, force the format

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: 19111@debbugs.gnu.org, Dani Moncayo <dmoncayo@gmail.com>
> Date: Fri, 21 Nov 2014 01:07:37 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If the user sets the triplet, it should be obeyed.  If it's incorrect,
> > that's the user's problem.
> >
> >> I understand your concern: `configure' can use the triplet anywhere and
> >> hence it is important that it is correct.
> >
> > Yes, exactly.
> >
> > Could you propose a patch along these lines?
> 
> Something like this, perhaps? (It should also work for Dani's Cygwin
> case.)

Yes, thanks.

> +      t=${t#Target: }

Is this portable to Unix shells?  If not, perhaps use the 'eval' trick
here.

> +      if test "x$t" = "x"; then
> +	  AC_MSG_ERROR([Impossible to determine $cc compiler target.
> +Please explicitly provide --target])

I would replace this with a warning and go with $canonical as it was
determined before.

Otherwise, I think this is good to go in, but please wait for a couple
of days to let others comment if they want.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> +      t=${t#Target: }
>
> Is this portable to Unix shells?  If not, perhaps use the 'eval' trick
> here.

This code is never meant to be executed on other than MSYS(2)/Cygwin.
Does the shell complain if an error is present inside an `if' that it
doesn't enter? In other words, does the shell perform syntactic checks
on code that it doesn't execute?

>> +      if test "x$t" = "x"; then
>> +	  AC_MSG_ERROR([Impossible to determine $cc compiler target.
>> +Please explicitly provide --target])
>
> I would replace this with a warning and go with $canonical as it was
> determined before.

`configure' outputs hundreds of messages on quick succession. Warnings
are useless for the average users (warnings just go unnoticed.) Apart
from that, if at the user's end the script fails to get the Target from
the compiler, we would like to know about that new compiler on
emacs-devel/bugs (gcc 4.x and clang should work; dunno about old gcc
versions but I expect that 3.x is fine too.)

> Otherwise, I think this is good to go in, but please wait for a couple
> of days to let others comment if they want.

Ok.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: 19111@debbugs.gnu.org
> Date: Fri, 21 Nov 2014 15:15:32 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> +      t=${t#Target: }
> >
> > Is this portable to Unix shells?  If not, perhaps use the 'eval' trick
> > here.
> 
> This code is never meant to be executed on other than MSYS(2)/Cygwin.
> Does the shell complain if an error is present inside an `if' that it
> doesn't enter? In other words, does the shell perform syntactic checks
> on code that it doesn't execute?

It does, sometimes.  I'll let experts to tell if this is one of those
cases.

> 
> >> +      if test "x$t" = "x"; then
> >> +	  AC_MSG_ERROR([Impossible to determine $cc compiler target.
> >> +Please explicitly provide --target])
> >
> > I would replace this with a warning and go with $canonical as it was
> > determined before.
> 
> `configure' outputs hundreds of messages on quick succession. Warnings
> are useless for the average users (warnings just go unnoticed.) Apart
> from that, if at the user's end the script fails to get the Target from
> the compiler, we would like to know about that new compiler on
> emacs-devel/bugs (gcc 4.x and clang should work; dunno about old gcc
> versions but I expect that 3.x is fine too.)

OTOH, we've lived without this test for quites some time, so suddenly
starting to reject any configurations that might cause this sounds too
drastic to me.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Dani Moncayo]

>> >> +      t=${t#Target: }
>> >
>> > Is this portable to Unix shells?  If not, perhaps use the 'eval' trick
>> > here.
>>
>> This code is never meant to be executed on other than MSYS(2)/Cygwin.
>> Does the shell complain if an error is present inside an `if' that it
>> doesn't enter? In other words, does the shell perform syntactic checks
>> on code that it doesn't execute?
>
> It does, sometimes.

Someone reported an error related to parameter expansion:

   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18612

So, it seems that, on some (rare) systems, the shell may complain
about sentences which will not be actually executed.

But in the example above the error was related to parameter expansion
of the form "${var:n:m}", which is different from the parameter
expansion you've used ("${var#foo}"), and the latter seems to be more
portable, according to this test I've just made (on Cygwin):

$ a=hello dash -c 'echo ${a:0:1}'
dash: 1: Bad substitution
$ a=hello dash -c 'echo ${a#he}'
llo

So, I'd go ahead with the patch.  If someone complains, we can apply
the same fix: indirect execution of the offending sentence through
"eval".

-- 
Dani Moncayo

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Glenn Morris]

https://www.gnu.org/software/autoconf/manual/autoconf-2.64/html_node/Shell-Substitutions.html
     
     ${#var}
     ${var%word}
     ${var%%word}
     ${var#word}
     ${var##word}
         Posix requires support for these usages, but they do not work with
         many traditional shells, e.g., Solaris 10 /bin/sh.
     
It's easy to replace this with something that we know is fine, using sed
or eval. So I'd do that. Cygwin is not a representative sample.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Dani Moncayo]

> It's easy to replace this with something that we know is fine, using sed
> or eval. So I'd do that. Cygwin is not a representative sample.

Well, Cygwin is not a shell, but a GNU-like system on top of MS-Windows.

My test used dash (debian alquimist shell [1]), which is probably the
shell reported to fail in [2].

[1] http://en.wikipedia.org/wiki/Almquist_shell
[2] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18612

-- 
Dani Moncayo

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Glenn Morris]

Dani Moncayo wrote:

>> It's easy to replace this with something that we know is fine, using sed
>> or eval. So I'd do that. Cygwin is not a representative sample.
>
> Well, Cygwin is not a shell, but a GNU-like system on top of MS-Windows.
>
> My test used dash (debian alquimist shell [1]), which is probably the
> shell reported to fail in [2].

I meant: the shells included in Cygwin are not representative of all the
weird old /bin/sh shells out there in Unix-land, on which people like to
build Emacs one week before (or after) the release, only to find it does
not configure.

It's trivial to avoid any problem. We already spent more time talking
about it than it would take to just fix it.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> +      t=${t#Target: }
>> >
>> > Is this portable to Unix shells?  If not, perhaps use the 'eval' trick
>> > here.
>> 
>> This code is never meant to be executed on other than MSYS(2)/Cygwin.
>> Does the shell complain if an error is present inside an `if' that it
>> doesn't enter? In other words, does the shell perform syntactic checks
>> on code that it doesn't execute?
>
> It does, sometimes.  I'll let experts to tell if this is one of those
> cases.

Ok. Now I have to figure out that 'eval' trick.

> OTOH, we've lived without this test for quites some time, so suddenly
> starting to reject any configurations that might cause this sounds too
> drastic to me.

Until recently there was a very limited set of MSYS/MinGW supported
architectures (one). This problem couldn't happen. Now we have i686 and
x86_64, which makes 4 MSYS/MinGW combinations and, of course, some users
experienced the problem.

IMO it is better to reject those cases where guessing the target
platform might cause cryptic errors later on the build (or at runtime).
The user can pass --target to `configure' to avoid the check, as its
error message says.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Dani Moncayo]

>> Could you propose a patch along these lines?
>
> Something like this, perhaps?

Óscar, I've tried your path from my usual MSYS/MinGW environment.

'./configure' ends up failing like this:

------------------------------------
[...]
checking for gawk... gawk
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking the compiler's target... mingw32
configure: error: Emacs does not support `mingw32' systems.
If you think it should, please send a report to bug-gnu-emacs@gnu.org.
Check `etc/MACHINES' for recognized configuration names.
------------------------------------


-- 
Dani Moncayo

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Dani Moncayo]

On Fri, Nov 21, 2014 at 6:56 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:
>>> Could you propose a patch along these lines?
>>
>> Something like this, perhaps?
>
> Óscar, I've tried your path from my usual MSYS/MinGW environment.
>
> './configure' ends up failing like this:
>
> ------------------------------------
> [...]
> checking for gawk... gawk
> checking build system type... i686-pc-mingw32
> checking host system type... i686-pc-mingw32
> checking the compiler's target... mingw32
> configure: error: Emacs does not support `mingw32' systems.
> If you think it should, please send a report to bug-gnu-emacs@gnu.org.
> Check `etc/MACHINES' for recognized configuration names.
> ------------------------------------

It seems that the new value of $canonical, obtained in this case via
"gcc -v", is lacking the "i686-pc-" prefix.

-- 
Dani Moncayo

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Dani Moncayo <dmoncayo@gmail.com> writes:

> It seems that the new value of $canonical, obtained in this case via
> "gcc -v", is lacking the "i686-pc-" prefix.

What's the output of `gcc -v' ?

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Dani Moncayo]

>> It seems that the new value of $canonical, obtained in this case via
>> "gcc -v", is lacking the "i686-pc-" prefix.
>
> What's the output of `gcc -v' ?

------------------------------------------------
$ gcc -v
Using built-in specs.
COLLECT_GCC=c:\mingw\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.7.2/configure
--enable-languages=c,c++,ada,fortran,objc,obj-c++
--disable-sjlj-exceptions --wi
th-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry
--enable-libstdcxx-debug --disable-build-poststage1-
with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.7.2 (GCC)
------------------------------------------------

But it seems that different flavors of MinGW compilers are not
consistent wrt the "Target" line shown there: for example, I've just
installed the mingw64-i686 toolchain in Cygwin, and there I get this:

------------------------------------------------
$ /usr/bin/i686-w64-mingw32-gcc.exe -v
Using built-in specs.
COLLECT_GCC=/usr/bin/i686-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/4.8.3/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with:
/cygdrive/i/szsz/tmpp/cygwin64/mingw64-i686/mingw64-i686-gcc-4.8.3-1/src/gcc-4.8.3/configure
--srcdir=/cygdrive/i/szsz/tmpp/cygwin64/mingw64-i686/mingw64-i686-gcc-4.8.3-1/src/gcc-4.8.3
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share
--docdir=/usr/share/doc/mingw64-i686-gcc
--htmldir=/usr/share/doc/mingw64-i686-gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin
--target=i686-w64-mingw32 --without-libiconv-prefix
--without-libintl-prefix --with-sysroot=/usr/i686-w64-mingw32/sys-root
--with-build-sysroot=/usr/i686-w64-mingw32/sys-root --disable-multilib
--disable-win32-registry
--enable-languages=c,ada,c++,fortran,lto,objc,obj-c++
--enable-fully-dynamic-strings --enable-graphite --enable-libgomp
--enable-libquadmath --enable-libquadmath-support --enable-libssp
--enable-version-specific-runtime-libs --with-dwarf2 --with-gnu-ld
--with-gnu-as --with-tune=generic
--with-cloog-include=/usr/include/cloog-isl --with-system-zlib
--libexecdir=/usr/lib
Thread model: win32
gcc version 4.8.3 (GCC)
------------------------------------------------

-- 
Dani Moncayo

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Dani Moncayo <dmoncayo@gmail.com> writes:

>> What's the output of `gcc -v' ?
>
> ------------------------------------------------
> $ gcc -v
[snip]
> Target: mingw32
[snip]
> with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
__________________________________________________________^^^^^^^

It seems that you can throw anything at the gcc `configure' script and
it will make sense of it.

I'll modify the patch to handle that case.

Gracias Dani.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

>> with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
> __________________________________________________________^^^^^^^
>
> It seems that you can throw anything at the gcc `configure' script and
> it will make sense of it.
>
> I'll modify the patch to handle that case.

This should cover Dani's case and the string replacement issue:


diff --git a/configure.ac b/configure.ac
index 5d71c2f..4a48810 100644
--- a/configure.ac
+++ b/configure.ac
@@ -145,6 +145,36 @@ case $canonical in
  *-mingw*)
   . $srcdir/nt/mingw-cfg.site
 
+  # When we build with MinGW under MSYS, we are cross-compiling. Hence
+  # we can't rely on the output of MSYS `uname' for the architecture
+  # (32 bit MinGW compiler with 64 bit MSYS2, for instance) and must
+  # use the compiler's target, unless when the user explicitly
+  # provides one:
+  if test -z $target_alias; then
+      AC_MSG_CHECKING([the compiler's target])
+      if test -z $CC; then
+	  cc=gcc
+      else
+	  cc=$CC
+      fi
+      t=$($cc -v 2>&1 | grep "^Target: ")
+      t=`echo $t | sed -e 's/Target: //'`
+      case "$t" in
+          *-*) canonical=$t
+	      ;;
+          "") AC_MSG_ERROR([Impossible to obtain $cc compiler target.
+Please explicitly provide --target])
+              ;;
+	  *) AC_MSG_WARN([Compiler reported non-standard target.
+Defaulting to $canonical.])
+              ;;
+      esac
+      AC_MSG_RESULT([$canonical])
+  else
+      canonical=$target_alias
+  fi
+
   case $srcdir in
     /* | ?:*)
       # srcdir is an absolute path.  In this case, force the format

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Glenn Morris]

Óscar Fuentes wrote:

> +      t=$($cc -v 2>&1 | grep "^Target: ")
> +      t=`echo $t | sed -e 's/Target: //'`

You can do that in one, eg:
t=`$cc -v 2>&1 | sed -n 's/^Target: *//p'`


https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Shell-Substitutions.html
also recommends to avoid $(), though I note we fail on that front already.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Glenn Morris <rgm@gnu.org> writes:

> You can do that in one, eg:
> t=`$cc -v 2>&1 | sed -n 's/^Target: *//p'`

Done. Thanks.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Pushed to master as 70d7aa8a289375a119f5d4e785c8a5882f0a2e99

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Dani Moncayo]

On Tue, Nov 25, 2014 at 3:38 AM, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Pushed to master as 70d7aa8a289375a119f5d4e785c8a5882f0a2e99

Thank you Óscar.

I've done some test, and there is something that looks wrong to me (I
know almost nothing about these things, so correct me if I'm wrong):

IIUC, the way to explicitly tell the "destination platform" (i.e. the
"host" platform) is with the --host parameter to 'configure'.  So I've
tried this from a MSYS2 (64 bit) environment:
--------------------------------------------------
$ ./autogen.sh
[...]
$ ./configure --host=i686-pc-mingw64
[...]
checking whether make supports nested variables... (cached) yes
checking build system type... x86_64-pc-mingw32
checking host system type... i686-pc-mingw64
checking the compiler's target... i686-w64-mingw32
checking for i686-pc-mingw64-gcc... no
checking for i686-pc-mingw64-cc... no
checking for i686-pc-mingw64-cl... no
checking for i686-pc-mingw64-clang... no
checking for i686-pc-mingw64-... no
checking for i686-pc-mingw64-... no
checking for gcc... gcc
checking whether the C compiler works... yes
[...]
--------------------------------------------------

IIUC, in that case the configure script should not check the
compiler's target, because I'm suplying that information in the --host
parameter.

I think that the problem is that you are checking $target_alias, when
TRT would be to check $host_alias instead (which holds the value of
the --host parameter).

Also, if we want to avoid "transient" values of $canonical, we could
set that variable only once, when we know its final value.

At the end of this message is a patch along these lines.  I've tested
it a bit and seems to work fine.  For example:
--------------------------------------------------
$ ./autogen.sh
[...]
$ ./configure --host=i686-pc-mingw64
[...]
checking whether make supports nested variables... (cached) yes
checking build system type... x86_64-pc-mingw32
checking host system type... i686-pc-mingw64
checking for i686-pc-mingw64-gcc... no
checking for i686-pc-mingw64-cc... no
checking for i686-pc-mingw64-cl... no
checking for i686-pc-mingw64-clang... no
checking for i686-pc-mingw64-... no
checking for i686-pc-mingw64-... no
checking for gcc... gcc
checking whether the C compiler works... yes
[...]
$ ./configure
[...]
checking whether make supports nested variables... (cached) yes
checking build system type... x86_64-pc-mingw32
checking host system type... x86_64-pc-mingw32
checking the compiler's target... i686-w64-mingw32
checking for gcc... gcc
checking whether the C compiler works... yes
[...]
--------------------------------------------------

Here is the patch against the current master HEAD:

--------------------------------------------------
diff --git a/configure.ac b/configure.ac
index 8830ec7..37dc74d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -137,42 +137,41 @@ AM_INIT_AUTOMAKE(1.11)

 dnl Canonicalize the configuration name.
 AC_CANONICAL_HOST
-canonical=$host
-configuration=${host_alias-${build_alias-$host}}

 dnl We get MINGW64 with MSYS2, MINGW32 with MSYS.
-case $canonical in
+case $host in
  *-mingw*)
-  . $srcdir/nt/mingw-cfg.site

   # When we build with MinGW under MSYS, we are cross-compiling. Hence
   # we can't rely on the output of MSYS `uname' for the architecture
   # (32 bit MinGW compiler with 64 bit MSYS2, for instance) and must
   # use the compiler's target, unless when the user explicitly
-  # provides one:
-  if test -z $target_alias; then
+  # provides a --host parameter
+  if test -n "$host_alias"; then
+      host=$host_alias
+  else
       AC_MSG_CHECKING([the compiler's target])
-      if test -z $CC; then
+      if test -z "$CC"; then
   cc=gcc
       else
   cc=$CC
       fi
       t=`$cc -v 2>&1 | sed -n 's/Target: //p'`
       case "$t" in
-          *-*) canonical=$t
+          *-*) host=$t
       ;;
           "") AC_MSG_ERROR([Impossible to obtain $cc compiler target.
-Please explicitly provide --target])
+Please explicitly provide --host.])
               ;;
   *) AC_MSG_WARN([Compiler reported non-standard target.
-Defaulting to $canonical.])
+Defaulting to $host.])
               ;;
       esac
-      AC_MSG_RESULT([$canonical])
-  else
-      canonical=$target_alias
+      AC_MSG_RESULT([$host])
   fi

+  . $srcdir/nt/mingw-cfg.site
+
   case $srcdir in
     /* | ?:*)
       # srcdir is an absolute path.  In this case, force the format
@@ -185,6 +184,9 @@ Defaulting to $canonical.])
   esac;;
 esac

+canonical=$host
+configuration=${host_alias-${build_alias-$host}}
+
 dnl Support for --program-prefix, --program-suffix and
 dnl --program-transform-name options
 AC_ARG_PROGRAM
--------------------------------------------------

-- 
Dani Moncayo

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Dani Moncayo <dmoncayo@gmail.com> writes:

> I've done some test, and there is something that looks wrong to me (I
> know almost nothing about these things, so correct me if I'm wrong):
>
> IIUC, the way to explicitly tell the "destination platform" (i.e. the
> "host" platform) is with the --host parameter to 'configure'.  So I've
> tried this from a MSYS2 (64 bit) environment:
> --------------------------------------------------
> $ ./autogen.sh
> [...]
> $ ./configure --host=i686-pc-mingw64
> [...]
> checking whether make supports nested variables... (cached) yes
> checking build system type... x86_64-pc-mingw32
> checking host system type... i686-pc-mingw64
> checking the compiler's target... i686-w64-mingw32
> checking for i686-pc-mingw64-gcc... no
> checking for i686-pc-mingw64-cc... no
> checking for i686-pc-mingw64-cl... no
> checking for i686-pc-mingw64-clang... no
> checking for i686-pc-mingw64-... no
> checking for i686-pc-mingw64-... no
> checking for gcc... gcc
> checking whether the C compiler works... yes
> [...]
> --------------------------------------------------
>
> IIUC, in that case the configure script should not check the
> compiler's target, because I'm suplying that information in the --host
> parameter.

Yes, you are correct. I spend too much time working on cross-compilers,
I guess.

> I think that the problem is that you are checking $target_alias, when
> TRT would be to check $host_alias instead (which holds the value of
> the --host parameter).
>
> Also, if we want to avoid "transient" values of $canonical, we could
> set that variable only once, when we know its final value.

The `transience' of $canonical is not about setting it before or after
the mingw check is made. The proposal on your previous e-mail suggested
to move the check after the "checking for gcc..." test. That's a big
leap when I work with the premise of altering only the parts that are
mingw-specific.

> At the end of this message is a patch along these lines.  I've tested
> it a bit and seems to work fine.  For example:

[snip]

The s/target/host part is ok. Moving $canonical to the end of the
mingw-specific code makes little sense. Overwriting it inside the
mingw-specific block is ok.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Dani Moncayo]

> The s/target/host part is ok. Moving $canonical to the end of the
> mingw-specific code makes little sense. Overwriting it inside the
> mingw-specific block is ok.

My intent is to keep consistency among $canonical, $host and
$configuration (which is not guaranteed currently).

IOW: what we actually want to determine is the host platform;
therefore, IMO it makes more sense to first get the correct value of
$host and then set $canonical and $configuration (which are based on
$host).

-- 
Dani Moncayo

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Dani Moncayo <dmoncayo@gmail.com> writes:

> My intent is to keep consistency among $canonical, $host and
> $configuration (which is not guaranteed currently).
>
> IOW: what we actually want to determine is the host platform;
> therefore, IMO it makes more sense to first get the correct value of
> $host and then set $canonical and $configuration (which are based on
> $host).

Ok. However, your patch fails to apply. It seems that it is built on a
previous local change on your repo.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Dani Moncayo]

[-- Attachment #1: Type: text/plain, Size: 239 bytes --]

> Ok. However, your patch fails to apply. It seems that it is built on a
> previous local change on your repo.

It might be due to GMail funny way of altering the user's text.

I'm attaching the last version of my patch.

-- 
Dani Moncayo

[-- Attachment #2: tmp.diff --]
[-- Type: text/plain, Size: 2354 bytes --]

diff --git a/configure.ac b/configure.ac
index 8830ec7..9908302 100644
--- a/configure.ac
+++ b/configure.ac
@@ -137,42 +137,44 @@ AM_INIT_AUTOMAKE(1.11)
 
 dnl Canonicalize the configuration name.
 AC_CANONICAL_HOST
-canonical=$host
-configuration=${host_alias-${build_alias-$host}}
 
-dnl We get MINGW64 with MSYS2, MINGW32 with MSYS.
-case $canonical in
+case $host in
  *-mingw*)
-  . $srcdir/nt/mingw-cfg.site
 
-  # When we build with MinGW under MSYS, we are cross-compiling. Hence
-  # we can't rely on the output of MSYS `uname' for the architecture
-  # (32 bit MinGW compiler with 64 bit MSYS2, for instance) and must
-  # use the compiler's target, unless when the user explicitly
-  # provides one:
-  if test -z $target_alias; then
+  # We are building with a MSYS[2]/MinGW[-w64] toolchain.
+
+  if test -z "$host_alias"; then
+
+      # No --host argument was given, but we cannot rely on the
+      # current value of '$host', because it is based on the MSYS[2]
+      # environment ('i686-pc-mingw32' on MSYS and MSYS2-i686, and
+      # 'x86_64-pc-mingw64' on MSYS2-x86_64), which may not match
+      # the actual compiler's target.  E.g. building with MSYS2-x86_64
+      # and MinGW-i686.  Therefore, we have to check the compiler's
+      # target.
+
       AC_MSG_CHECKING([the compiler's target])
-      if test -z $CC; then
+      if test -z "$CC"; then
 	  cc=gcc
       else
 	  cc=$CC
       fi
       t=`$cc -v 2>&1 | sed -n 's/Target: //p'`
       case "$t" in
-          *-*) canonical=$t
+          *-*) host=$t
 	      ;;
           "") AC_MSG_ERROR([Impossible to obtain $cc compiler target.
-Please explicitly provide --target])
+Please explicitly provide --host.])
               ;;
 	  *) AC_MSG_WARN([Compiler reported non-standard target.
-Defaulting to $canonical.])
+Defaulting to $host.])
               ;;
       esac
-      AC_MSG_RESULT([$canonical])
-  else
-      canonical=$target_alias
+      AC_MSG_RESULT([$host])
   fi
 
+  . $srcdir/nt/mingw-cfg.site
+
   case $srcdir in
     /* | ?:*)
       # srcdir is an absolute path.  In this case, force the format
@@ -185,6 +187,9 @@ Defaulting to $canonical.])
   esac;;
 esac
 
+canonical=$host
+configuration=${host_alias-${build_alias-$host}}
+
 dnl Support for --program-prefix, --program-suffix and
 dnl --program-transform-name options
 AC_ARG_PROGRAM

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Dani Moncayo <dmoncayo@gmail.com> writes:

> I'm attaching the last version of my patch.

Ok. Let's wait for Eli's review.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: 19111@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Wed, 26 Nov 2014 01:00:47 +0100
> 
> Dani Moncayo <dmoncayo@gmail.com> writes:
> 
> > I'm attaching the last version of my patch.
> 
> Ok. Let's wait for Eli's review.

I have no opinion about that; if you two agree, go ahead and commit.

Thanks.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Dani Moncayo]

>> > I'm attaching the last version of my patch.
>>
>> Ok. Let's wait for Eli's review.
>
> I have no opinion about that; if you two agree, go ahead and commit.

Done.  Thanks.

-- 
Dani Moncayo

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Dani Moncayo]

[-- Attachment #1: Type: text/plain, Size: 3031 bytes --]

Hello,

I have to say that I still don't like the way of determining the host
platform on MinGW builds, because we are setting $host and $canonical
to a value (the compiler's target) that is not guaranteed to be
canonical (and in fact is not canonical in the cases I've tried, see
below).

The following table shows the canonical host (as given by
'build-aux/config.guess') and gcc target taken from the 5 different
build environments for MS-Windows I know of:

#  MSYS type     $MSYSTEM   canonical host      gcc target
-  -----------   --------   -----------------   ------------------
1  MSYS          MINGW32    i686-pc-mingw32     mingw32
2  MSYS2-32bit   MINGW32    i686-pc-mingw32     i686-w64-mingw32
3  MSYS2-32bit   MINGW64    i686-pc-mingw64     x86_64-w64-mingw32
4  MSYS2-64bit   MINGW32    x86_64-pc-mingw32   i686-w64-mingw32
5  MSYS2-64bit   MINGW64    x86_64-pc-mingw64   x86_64-w64-mingw32
------------------------------------------------------------------

As you can see, our problem is only in the environments 3 and 4, where
the first part of the canonical triplet (CPU in CPU-VENDOR-OS) is not
what we want.

But note that this problem is easily fixable: the CPU we want can be
deduced from the OS part of the triplet:
* mingw32 --> i686
* mingw64 --> x86_64

The following patch (also attached) is an attempt to fix this.

WDYT?

diff --git a/configure.ac b/configure.ac
index 010abc8..d7a17f2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -142,32 +142,18 @@ case $host in
  *-mingw*)

   if test -z "$host_alias"; then
-
-      # No --host argument was given to 'configure'; therefore $host
-      # was set to a default value based on the build platform.  But
-      # this default value may be wrong if we are building from a
-      # 64-bit MSYS[2] pre-configured to build 32-bit MinGW programs.
-      # Therefore, we'll try to get the right host platform from the
-      # compiler's target.
-
-      AC_MSG_CHECKING([the compiler's target])
-      if test -z "$CC"; then
-  cc=gcc
-      else
-  cc=$CC
-      fi
-      cc_target=`$cc -v 2>&1 | sed -n 's/Target: //p'`
-      case "$cc_target" in
-          *-*) host=$cc_target
-      ;;
-          "") AC_MSG_ERROR([Impossible to obtain $cc compiler target.
-Please explicitly provide --host.])
-              ;;
-  *) AC_MSG_WARN([Compiler reported non-standard target.
-Defaulting to $host.])
-              ;;
-      esac
-      AC_MSG_RESULT([$host])
+    # No --host argument was given; therefore $host was set to $build.
+    # But this default value is wrong if we are building from MSYS2
+    # 64-bit with the mingw32 shell, or from MSYS2 32-bit with the
+    # mingw64 shell.  So we have to amend $host in those cases.
+    host1=`AS_ECHO $host | sed \
+      -e 's/x86_64-pc-mingw32/i686-pc-mingw32/' \
+      -e 's/i686-pc-mingw64/x86_64-pc-mingw64/'`
+
+    if test "$host1" != "$host"; then
+      host=$host1
+      AC_MSG_WARN([host system type amended to $host])
+    fi
   fi

   . $srcdir/nt/mingw-cfg.site



-- 
Dani Moncayo

[-- Attachment #2: tmp.diff --]
[-- Type: text/plain, Size: 1663 bytes --]

diff --git a/configure.ac b/configure.ac
index 010abc8..d7a17f2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -142,32 +142,18 @@ case $host in
  *-mingw*)
 
   if test -z "$host_alias"; then
-
-      # No --host argument was given to 'configure'; therefore $host
-      # was set to a default value based on the build platform.  But
-      # this default value may be wrong if we are building from a
-      # 64-bit MSYS[2] pre-configured to build 32-bit MinGW programs.
-      # Therefore, we'll try to get the right host platform from the
-      # compiler's target.
-
-      AC_MSG_CHECKING([the compiler's target])
-      if test -z "$CC"; then
-	  cc=gcc
-      else
-	  cc=$CC
-      fi
-      cc_target=`$cc -v 2>&1 | sed -n 's/Target: //p'`
-      case "$cc_target" in
-          *-*) host=$cc_target
-	      ;;
-          "") AC_MSG_ERROR([Impossible to obtain $cc compiler target.
-Please explicitly provide --host.])
-              ;;
-	  *) AC_MSG_WARN([Compiler reported non-standard target.
-Defaulting to $host.])
-              ;;
-      esac
-      AC_MSG_RESULT([$host])
+    # No --host argument was given; therefore $host was set to $build.
+    # But this default value is wrong if we are building from MSYS2
+    # 64-bit with the mingw32 shell, or from MSYS2 32-bit with the
+    # mingw64 shell.  So we have to amend $host in those cases.
+    host1=`AS_ECHO $host | sed \
+      -e 's/x86_64-pc-mingw32/i686-pc-mingw32/' \
+      -e 's/i686-pc-mingw64/x86_64-pc-mingw64/'`
+
+    if test "$host1" != "$host"; then
+      host=$host1
+      AC_MSG_WARN([host system type amended to $host])
+    fi
   fi
 
   . $srcdir/nt/mingw-cfg.site

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Eli Zaretskii]

> Date: Sat, 29 Nov 2014 11:07:14 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> I have to say that I still don't like the way of determining the host
> platform on MinGW builds, because we are setting $host and $canonical
> to a value (the compiler's target) that is not guaranteed to be
> canonical (and in fact is not canonical in the cases I've tried, see
> below).

Why do you think it isn't canonical?  For that matter, what is your
definition of "canonical" in this context?

> The following table shows the canonical host (as given by
> 'build-aux/config.guess') and gcc target taken from the 5 different
> build environments for MS-Windows I know of:
> 
> #  MSYS type     $MSYSTEM   canonical host      gcc target
> -  -----------   --------   -----------------   ------------------
> 1  MSYS          MINGW32    i686-pc-mingw32     mingw32
> 2  MSYS2-32bit   MINGW32    i686-pc-mingw32     i686-w64-mingw32
> 3  MSYS2-32bit   MINGW64    i686-pc-mingw64     x86_64-w64-mingw32
> 4  MSYS2-64bit   MINGW32    x86_64-pc-mingw32   i686-w64-mingw32
> 5  MSYS2-64bit   MINGW64    x86_64-pc-mingw64   x86_64-w64-mingw32
> ------------------------------------------------------------------
> 
> As you can see, our problem is only in the environments 3 and 4, where
> the first part of the canonical triplet (CPU in CPU-VENDOR-OS) is not
> what we want.

Verification of the canonical configurations is the job of the
config.sub script.  In this case, it considers all the "gcc target"
strings valid and outputs them intact, with a single exception: it
replaces "mingw32" with "i386-pc-mingw32", which is correct because
the mingw.org's development toolchain targets that host.

I'm guessing you somehow think that the "pc" part must be there
verbatim.  But that is incorrect: it is just the default value of
MANUFACTURER when the configuration type supplied "by other means"
doesn't provide a MANUFACTURER.  Since the *-w64-*-mingw32
configurations do provide MANUFACTURER, there's nothing wrong with
them, and they cannot cause any harm, AFAIK.

> But note that this problem is easily fixable: the CPU we want can be
> deduced from the OS part of the triplet:
> * mingw32 --> i686
> * mingw64 --> x86_64

I don't think we need that, since what we have now uses perfectly
valid canonical configuration types.  In any case, if you still are
unconvinced, the way to fix this is to submit patches for config.sub,
so that it does this mapping automatically.  Its that script's job,
not ours.

Thanks.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Dani Moncayo]

On Sat, Nov 29, 2014 at 11:32 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 29 Nov 2014 11:07:14 +0100
>> From: Dani Moncayo <dmoncayo@gmail.com>
>>
>> I have to say that I still don't like the way of determining the host
>> platform on MinGW builds, because we are setting $host and $canonical
>> to a value (the compiler's target) that is not guaranteed to be
>> canonical (and in fact is not canonical in the cases I've tried, see
>> below).
>
> Why do you think it isn't canonical?

$host is not guaranteed to be canonical, because its (final) value is
not produced by our AC_CANONICAL_HOST.

> For that matter, what is your
> definition of "canonical" in this context?

The value of $host produced by AC_CANONICAL_HOST.

> Verification of the canonical configurations is the job of the
> config.sub script.

IIUC, the job of config.sub is verification/canonization of
configurations supplied explicitly as parameters in the configure
script (--host, --build).

> In this case, it considers all the "gcc target"
> strings valid and outputs them intact, with a single exception: it
> replaces "mingw32" with "i386-pc-mingw32", which is correct because
> the mingw.org's development toolchain targets that host.

Which means that all the gcc targets in my previous mail could be
specified to 'configure' as --host.

> I'm guessing you somehow think that the "pc" part must be there
> verbatim.  But that is incorrect: it is just the default value of
> MANUFACTURER when the configuration type supplied "by other means"
> doesn't provide a MANUFACTURER.  Since the *-w64-*-mingw32
> configurations do provide MANUFACTURER, there's nothing wrong with
> them, and they cannot cause any harm, AFAIK.

I think that the "w64" manufacturer reveals that something is not
quite right, because, when no --host and --build are specified, the
canonical configuration should be the one produced by config.guess,
and this script always uses 'pc' as MANUFACTURER (for MinGW-type
systems).

>> But note that this problem is easily fixable: the CPU we want can be
>> deduced from the OS part of the triplet:
>> * mingw32 --> i686
>> * mingw64 --> x86_64
>
> I don't think we need that, since what we have now uses perfectly
> valid canonical configuration types.  In any case, if you still are
> unconvinced, the way to fix this is to submit patches for config.sub,
> so that it does this mapping automatically.  Its that script's job,
> not ours.

I agree with the above, after replacing 'config.sub' with
'config.guess'.

I've tried to make a patch for this, but it seems that 'config.guess'
is produced by 'autogen.sh', which in turn invokes autoreconf... and
this stuff is unknown to me for now.

But in summary: IMO, the right fix for this seems to be in
config.guess, which returns the wrong CPU on certain MSYS environments
(#3 and #4 in my previous mail).  This should be fixed and then
'configure.ac' should return to its previous state:

diff --git a/configure.ac b/configure.ac
index 010abc8..ca037ff 100644
--- a/configure.ac
+++ b/configure.ac
@@ -137,39 +137,12 @@ AM_INIT_AUTOMAKE(1.11)

 dnl Canonicalize the configuration name.
 AC_CANONICAL_HOST
+canonical=$host
+configuration=${host_alias-${build_alias-$host}}

-case $host in
+case $canonical in
  *-mingw*)

-  if test -z "$host_alias"; then
-
-      # No --host argument was given to 'configure'; therefore $host
-      # was set to a default value based on the build platform.  But
-      # this default value may be wrong if we are building from a
-      # 64-bit MSYS[2] pre-configured to build 32-bit MinGW programs.
-      # Therefore, we'll try to get the right host platform from the
-      # compiler's target.
-
-      AC_MSG_CHECKING([the compiler's target])
-      if test -z "$CC"; then
-  cc=gcc
-      else
-  cc=$CC
-      fi
-      cc_target=`$cc -v 2>&1 | sed -n 's/Target: //p'`
-      case "$cc_target" in
-          *-*) host=$cc_target
-      ;;
-          "") AC_MSG_ERROR([Impossible to obtain $cc compiler target.
-Please explicitly provide --host.])
-              ;;
-  *) AC_MSG_WARN([Compiler reported non-standard target.
-Defaulting to $host.])
-              ;;
-      esac
-      AC_MSG_RESULT([$host])
-  fi
-
   . $srcdir/nt/mingw-cfg.site

   case $srcdir in
@@ -184,9 +157,6 @@ Defaulting to $host.])
   esac;;
 esac

-canonical=$host
-configuration=${host_alias-${build_alias-$host}}
-
 dnl Support for --program-prefix, --program-suffix and
 dnl --program-transform-name options
 AC_ARG_PROGRAM


-- 
Dani Moncayo

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Eli Zaretskii]

> Date: Sat, 29 Nov 2014 19:22:47 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 19111@debbugs.gnu.org
> 
> > Why do you think it isn't canonical?
> 
> $host is not guaranteed to be canonical, because its (final) value is
> not produced by our AC_CANONICAL_HOST.
> 
> > For that matter, what is your
> > definition of "canonical" in this context?
> 
> The value of $host produced by AC_CANONICAL_HOST.

That's an arbitrary definition, which I think is unnecessarily
restrictive.

> > Verification of the canonical configurations is the job of the
> > config.sub script.
> 
> IIUC, the job of config.sub is verification/canonization of
> configurations supplied explicitly as parameters in the configure
> script (--host, --build).

I don't think I agree.  What is your basis for that assertion?

> I think that the "w64" manufacturer reveals that something is not
> quite right, because, when no --host and --build are specified, the
> canonical configuration should be the one produced by config.guess,

Ideally, yes.  But that's not really necessary, if the MANUFACTURER
part doesn't affect the build (as it is in this case).

> > I don't think we need that, since what we have now uses perfectly
> > valid canonical configuration types.  In any case, if you still are
> > unconvinced, the way to fix this is to submit patches for config.sub,
> > so that it does this mapping automatically.  Its that script's job,
> > not ours.
> 
> I agree with the above, after replacing 'config.sub' with
> 'config.guess'.

config.guess just calls 'uname'.

> But in summary: IMO, the right fix for this seems to be in
> config.guess, which returns the wrong CPU on certain MSYS environments
> (#3 and #4 in my previous mail).

I don't object to making such a change in config.guess, but I still
think replacing -w64- with -pc- is not really necessary, as the former
does no harm, and most probably never will.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Dani Moncayo]

>> > Verification of the canonical configurations is the job of the
>> > config.sub script.
>>
>> IIUC, the job of config.sub is verification/canonization of
>> configurations supplied explicitly as parameters in the configure
>> script (--host, --build).
>
> I don't think I agree.  What is your basis for that assertion?

My basis is the analysis of my configure script.  config.sub is called
twice,

a. To produce the canonical $build from $build_alias (i.e. the --build
   parameter), when it is set.
b. Likewise, for the canonical $host.

>> > I don't think we need that, since what we have now uses perfectly
>> > valid canonical configuration types.  In any case, if you still are
>> > unconvinced, the way to fix this is to submit patches for config.sub,
>> > so that it does this mapping automatically.  Its that script's job,
>> > not ours.
>>
>> I agree with the above, after replacing 'config.sub' with
>> 'config.guess'.
>
> config.guess just calls 'uname'.

Yes, it is based on uname's output, which seems wrong in certain cases
(see my previous mail).

>> But in summary: IMO, the right fix for this seems to be in
>> config.guess, which returns the wrong CPU on certain MSYS environments
>> (#3 and #4 in my previous mail).
>
> I don't object to making such a change in config.guess, but I still
> think replacing -w64- with -pc- is not really necessary, as the former
> does no harm, and most probably never will.

Well, my proposal is not to replace -w64- with -pc- but to find a
better way of fixing the problem reported in this thread.

As for the change, as I said, I don't know how to make the change to
config.guess, because it's a generated file, and I don't know where it
comes from ultimately.

-- 
Dani Moncayo

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Eli Zaretskii]

> Date: Sat, 29 Nov 2014 20:25:40 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 19111@debbugs.gnu.org
> 
> >> > Verification of the canonical configurations is the job of the
> >> > config.sub script.
> >>
> >> IIUC, the job of config.sub is verification/canonization of
> >> configurations supplied explicitly as parameters in the configure
> >> script (--host, --build).
> >
> > I don't think I agree.  What is your basis for that assertion?
> 
> My basis is the analysis of my configure script.  config.sub is called
> twice,
> 
> a. To produce the canonical $build from $build_alias (i.e. the --build
>    parameter), when it is set.
> b. Likewise, for the canonical $host.

That just supports my view of what it does.

> Well, my proposal is not to replace -w64- with -pc- but to find a
> better way of fixing the problem reported in this thread.

There's nothing wrong with the way we fixed it.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Dani Moncayo]

Ok, I was misunderstanding things, as expected.  This use to happen
when one decides to talk about things one know little about :-).

Just for the record: I hate hacks, so I obviously don't want to push
them further.  What I proposed was based on misunderstandings.  In
fact, I'd definitely prefer to just revert these changes.  If some
user bumped into this problem again, just teach him/her to provide a
proper --host.

Sorry for wasting your time, guys.

-- 
Dani Moncayo

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Eli Zaretskii]

> Date: Sat, 29 Nov 2014 21:37:11 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> Sorry for wasting your time, guys.

Time spent discussing important issues is not time wasted.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Dani Moncayo <dmoncayo@gmail.com> writes:

> But note that this problem is easily fixable: the CPU we want can be
> deduced from the OS part of the triplet:
> * mingw32 --> i686
> * mingw64 --> x86_64

I wouldn't hold much expectations from the mingw64 part. I've seen it
disputed multiple times saying that it should be mingw32 and, IIRC,
their reasoning seemed sound.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Dani Moncayo]

>> But note that this problem is easily fixable: the CPU we want can be
>> deduced from the OS part of the triplet:
>> * mingw32 --> i686
>> * mingw64 --> x86_64
>
> I wouldn't hold much expectations from the mingw64 part. I've seen it
> disputed multiple times saying that it should be mingw32 and, IIRC,
> their reasoning seemed sound.

Actually I think that there should be no need for that guessing of the
CPU architecture.  If MSYS2 provides both 32 and 64 bit build
environments, each environment should be configured so that 'uname -m'
produced the intended CPU architecture.

-- 
Dani Moncayo

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Eli Zaretskii]

> Date: Sat, 29 Nov 2014 19:37:38 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 19111@debbugs.gnu.org
> 
> If MSYS2 provides both 32 and 64 bit build environments, each
> environment should be configured so that 'uname -m' produced the
> intended CPU architecture.

You are asking the impossible: how can 'uname' know which code will be
produced by a compiler that will be invoked by 'make'?

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Dani Moncayo]

>> If MSYS2 provides both 32 and 64 bit build environments, each
>> environment should be configured so that 'uname -m' produced the
>> intended CPU architecture.
>
> You are asking the impossible: how can 'uname' know which code will be
> produced by a compiler that will be invoked by 'make'?

I may be misundertanding things; I'll try to explain what's on my
head.

As I see it, MSYS2 (either its 32 or 64-bit version) comes with two
ways of invoking bash: mingw32_shell.bat and mingw64_shell.bat.

IIUC, this gives the user two _build_ environments: one tuned for
building 32-bit MinGW programs and other for 64-bit.

So, if I enter the 32-bit _build_ environment and I build Emacs with a
plain 'configure && make', I'd expect it to work out of the box.  But
as we've seen, it doesn't.  Why? -> Because the canonical host
platform (picked up by default) has a wrong CPU.  And why? -> Because
the canonical _build_ platform picked (up by default) has a wrong CPU.
And why? -> because 'uname -m' gives 'x86_64' in a build environment
that pretends to be tuned for 32 bits.

-- 
Dani Moncayo

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Achim Gratz]

Dani Moncayo writes:
> So, if I enter the 32-bit _build_ environment and I build Emacs with a
> plain 'configure && make', I'd expect it to work out of the box.  But
> as we've seen, it doesn't.  Why? -> Because the canonical host
> platform (picked up by default) has a wrong CPU.  And why? -> Because
> the canonical _build_ platform picked (up by default) has a wrong CPU.
> And why? -> because 'uname -m' gives 'x86_64' in a build environment
> that pretends to be tuned for 32 bits.

So, uname tells you about the build environment.  Which is, as you've
seen, not the same as the compiler target.  You will have exactly that
same issue in any cross-compiling environment.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Andreas Schwab]

Achim Gratz <Stromeko@nexgo.de> writes:

> Dani Moncayo writes:
>> So, if I enter the 32-bit _build_ environment and I build Emacs with a
>> plain 'configure && make', I'd expect it to work out of the box.  But
>> as we've seen, it doesn't.  Why? -> Because the canonical host
>> platform (picked up by default) has a wrong CPU.  And why? -> Because
>> the canonical _build_ platform picked (up by default) has a wrong CPU.
>> And why? -> because 'uname -m' gives 'x86_64' in a build environment
>> that pretends to be tuned for 32 bits.
>
> So, uname tells you about the build environment.  Which is, as you've
> seen, not the same as the compiler target.  You will have exactly that
> same issue in any cross-compiling environment.

Or with any bi-arch compiler.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Dani Moncayo <dmoncayo@gmail.com> writes:

> As I see it, MSYS2 (either its 32 or 64-bit version) comes with two
> ways of invoking bash: mingw32_shell.bat and mingw64_shell.bat.
>
> IIUC, this gives the user two _build_ environments: one tuned for
> building 32-bit MinGW programs and other for 64-bit.

One places /mingw32/bin on the PATH, the other places /mingw64/bin on
the PATH. They also set MSYSTEM. That's all.

> So, if I enter the 32-bit _build_ environment and I build Emacs with a
> plain 'configure && make', I'd expect it to work out of the box.  But
> as we've seen, it doesn't.  Why? -> Because the canonical host
> platform (picked up by default) has a wrong CPU.  And why? -> Because
> the canonical _build_ platform picked (up by default) has a wrong CPU.
> And why? -> because 'uname -m' gives 'x86_64' in a build environment
> that pretends to be tuned for 32 bits.

`uname' has nothing to do with the toolset you are going to use.

The scenario is similar to building on a x86_64 GNU/Linux box targeting
i686. You can build and *run* the software on 32 bit mode on that same
machine. Certainly, nobody expects that `uname' changes its output
depending on how do you plan to build the software.

Usually, the user would be required to explicitly declare their intended
host platform when there is a mismatch of MSYS2 arch/MinGW-w64 arch.
What I submitted was a hack that exploits an MSYS2 idiosyncrasy for
relieving the user from that work and, more important, avoiding a
puzzling build error. You now propose to translate the hack to MSYS2
`uname'. That's going too far, IMO.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Eli Zaretskii]

> Date: Sat, 29 Nov 2014 20:23:31 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Óscar Fuentes <ofv@wanadoo.es>, 19111@debbugs.gnu.org
> 
> As I see it, MSYS2 (either its 32 or 64-bit version) comes with two
> ways of invoking bash: mingw32_shell.bat and mingw64_shell.bat.
> 
> IIUC, this gives the user two _build_ environments: one tuned for
> building 32-bit MinGW programs and other for 64-bit.

That's just a convenience vehicle.  A user can invoke a 32-bit or a
64-bit compiler without running those batch files.

> So, if I enter the 32-bit _build_ environment and I build Emacs with a
> plain 'configure && make', I'd expect it to work out of the box.  But
> as we've seen, it doesn't.  Why? -> Because the canonical host
> platform (picked up by default) has a wrong CPU.  And why? -> Because
> the canonical _build_ platform picked (up by default) has a wrong CPU.
> And why? -> because 'uname -m' gives 'x86_64' in a build environment
> that pretends to be tuned for 32 bits.

You may wish to re-read the beginning of this bug.  There, I explained
that using a MinGW64 compiler to produce a 32-bit binary is a kind of
cross-compilation, as far as a toolchain running on a 64-bit machine
is concerned.  Therefore, we could require the users that do such a
thing to provide explicit host at configure time.  Óscar wanted to be
nicer to MinGW64 users, so we went one more step towards them.

But it would be IMO wrong to develop a theory out of that.  In theory,
they should provide a configuration type, period.  Neither MSYS2 nor
its 'uname' can do that job.  We tweaked our configury because we
decided to do so, and as long as it works, I see no need for pushing
that any further.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Dani Moncayo]

Another detail that I think is wrong in the MinGW-specific block of
code is this: if a --host parameter was given to 'configure', there is
no need to update anything there.

So, here is the last version of my proposed patch:

-------------------------------------------------------
diff --git a/configure.ac b/configure.ac
index 8830ec7..3814104 100644
--- a/configure.ac
+++ b/configure.ac
@@ -137,42 +137,44 @@ AM_INIT_AUTOMAKE(1.11)

 dnl Canonicalize the configuration name.
 AC_CANONICAL_HOST
-canonical=$host
-configuration=${host_alias-${build_alias-$host}}

-dnl We get MINGW64 with MSYS2, MINGW32 with MSYS.
-case $canonical in
+case $host in
  *-mingw*)
-  . $srcdir/nt/mingw-cfg.site

-  # When we build with MinGW under MSYS, we are cross-compiling. Hence
-  # we can't rely on the output of MSYS `uname' for the architecture
-  # (32 bit MinGW compiler with 64 bit MSYS2, for instance) and must
-  # use the compiler's target, unless when the user explicitly
-  # provides one:
-  if test -z $target_alias; then
+  # We are building with a MSYS[2]/MinGW[-w64] toolchain.
+
+  if test -z "$host_alias"; then
+
+      # No --host argument was given, but we cannot rely on the
+      # current value of '$host', because it is based on the MSYS[2]
+      # environment ('i686-pc-mingw32' on MSYS and MSYS2-i686, and
+      # 'x86_64-pc-mingw64' on MSYS2-x86_64), which may not match
+      # the actual compiler's target.  E.g. building with MSYS2-x86_64
+      # and MinGW-i686.  Therefore, we have to check the compiler's
+      # target.
+
       AC_MSG_CHECKING([the compiler's target])
-      if test -z $CC; then
+      if test -z "$CC"; then
   cc=gcc
       else
   cc=$CC
       fi
       t=`$cc -v 2>&1 | sed -n 's/Target: //p'`
       case "$t" in
-          *-*) canonical=$t
+          *-*) host=$t
       ;;
           "") AC_MSG_ERROR([Impossible to obtain $cc compiler target.
-Please explicitly provide --target])
+Please explicitly provide --host.])
               ;;
   *) AC_MSG_WARN([Compiler reported non-standard target.
-Defaulting to $canonical.])
+Defaulting to $host.])
               ;;
       esac
-      AC_MSG_RESULT([$canonical])
-  else
-      canonical=$target_alias
+      AC_MSG_RESULT([$host])
   fi

+  . $srcdir/nt/mingw-cfg.site
+
   case $srcdir in
     /* | ?:*)
       # srcdir is an absolute path.  In this case, force the format
@@ -185,6 +187,9 @@ Defaulting to $canonical.])
   esac;;
 esac

+canonical=$host
+configuration=${host_alias-${build_alias-$host}}
+
 dnl Support for --program-prefix, --program-suffix and
 dnl --program-transform-name options
 AC_ARG_PROGRAM
-------------------------------------------------------

-- 
Dani Moncayo

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Dani Moncayo]

> This should cover Dani's case and the string replacement issue:

With this second patch, 'configure' doesn't fail.

This is the relevant portion of the 'configure's output:

------------------------------------------
[...]
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking the compiler's target... configure: WARNING: Compiler
reported non-standard target.
Defaulting to i686-pc-mingw32.
i686-pc-mingw32
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
[...]
------------------------------------------

Things that I find extrange, FWIW:

1. The check for the compiler's target goes before the check for gcc.
   But the former might need to ivoke the compiler (as in my case). So
   aparently the order of these checks should be swapped.

2. If I'm cross compiling, why the last check above says the contrary?

-- 
Dani Moncayo

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Eli Zaretskii]

> Date: Sat, 22 Nov 2014 09:46:42 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 19111@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> 
> 2. If I'm cross compiling, why the last check above says the contrary?

You are not cross-compiling, as far as the build process is concerned,
only as far as MSYS's uname is concerned.

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host

[Óscar Fuentes]

Dani Moncayo <dmoncayo@gmail.com> writes:

> Things that I find extrange, FWIW:
>
> 1. The check for the compiler's target goes before the check for gcc.
>    But the former might need to ivoke the compiler (as in my case). So
>    aparently the order of these checks should be swapped.

That's intentional, to not scatter mingw special cases even further and
to have $canonical fixed on the spot where it is introduced, avoiding
the risk of intermediate uses.

> 2. If I'm cross compiling, why the last check above says the contrary?

As Eli says.

Thanks for testing.