[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base w
From: |
Dani Moncayo |
Subject: |
bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host |
Date: |
Sat, 29 Nov 2014 19:22:47 +0100 |
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, (continued)
- bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host, Dani Moncayo, 2014/11/25
- bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host, Óscar Fuentes, 2014/11/25
- bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host, Dani Moncayo, 2014/11/25
- bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host, Óscar Fuentes, 2014/11/25
- bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host, Dani Moncayo, 2014/11/25
- bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host, Óscar Fuentes, 2014/11/25
- bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host, Eli Zaretskii, 2014/11/25
- bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host, Dani Moncayo, 2014/11/26
- bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host, Dani Moncayo, 2014/11/29
- bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host, Eli Zaretskii, 2014/11/29
- bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows 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, Eli Zaretskii, 2014/11/29
- bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host, Dani Moncayo, 2014/11/29
- bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host, Eli Zaretskii, 2014/11/29
- bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host, Dani Moncayo, 2014/11/29
- bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host, Eli Zaretskii, 2014/11/29
- bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host, Óscar Fuentes, 2014/11/29
- bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host, Dani Moncayo, 2014/11/29
- bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host, Eli Zaretskii, 2014/11/29
- bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host, Dani Moncayo, 2014/11/29
- bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host, Achim Gratz, 2014/11/29