From: "Óscar Fuentes" <ofv@wanadoo.es>
To: Dani Moncayo <dmoncayo@gmail.com>
Cc: 19111@debbugs.gnu.org
Subject: bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host
Date: Tue, 25 Nov 2014 21:52:04 +0100 [thread overview]
Message-ID: <87egsrnguj.fsf@wanadoo.es> (raw)
In-Reply-To: <CAH8Pv0hjZCR0SmsKL9kVSQ0283LNABgOk_pRfJJ8TRGtMLZUiQ@mail.gmail.com> (Dani Moncayo's message of "Tue, 25 Nov 2014 21:26:41 +0100")
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.
next prev parent reply other threads:[~2014-11-25 20:52 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-19 20:27 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-19 20:40 ` Eli Zaretskii
2014-11-19 21:27 ` Óscar Fuentes
2014-11-19 21:50 ` Óscar Fuentes
2014-11-19 22:01 ` Óscar Fuentes
2014-11-20 3:45 ` Eli Zaretskii
2014-11-20 3:43 ` Eli Zaretskii
2014-11-20 3:41 ` Eli Zaretskii
2014-11-20 4:10 ` Óscar Fuentes
2014-11-20 16:05 ` Eli Zaretskii
2014-11-20 16:23 ` Óscar Fuentes
2014-11-20 17:12 ` Eli Zaretskii
2014-11-20 18:30 ` Óscar Fuentes
2014-11-20 19:12 ` Dani Moncayo
2014-11-20 21:03 ` Eli Zaretskii
2014-11-21 0:07 ` Óscar Fuentes
2014-11-21 8:28 ` Eli Zaretskii
2014-11-21 14:15 ` Óscar Fuentes
2014-11-21 15:03 ` Eli Zaretskii
2014-11-21 16:06 ` Dani Moncayo
2014-11-21 17:02 ` Glenn Morris
2014-11-21 17:17 ` Dani Moncayo
2014-11-21 17:21 ` Glenn Morris
2014-11-21 18:12 ` Óscar Fuentes
2014-11-21 17:56 ` Dani Moncayo
2014-11-21 18:01 ` Dani Moncayo
2014-11-21 18:21 ` Óscar Fuentes
2014-11-21 18:34 ` Dani Moncayo
2014-11-21 18:41 ` Óscar Fuentes
2014-11-21 22:54 ` Óscar Fuentes
2014-11-22 1:05 ` Glenn Morris
2014-11-22 1:13 ` Óscar Fuentes
2014-11-25 2:38 ` Óscar Fuentes
2014-11-25 20:26 ` Dani Moncayo
2014-11-25 20:52 ` Óscar Fuentes [this message]
2014-11-25 21:13 ` Dani Moncayo
2014-11-25 23:41 ` Óscar Fuentes
2014-11-25 23:46 ` Dani Moncayo
2014-11-26 0:00 ` Óscar Fuentes
2014-11-26 3:49 ` Eli Zaretskii
2014-11-26 20:05 ` Dani Moncayo
2014-11-29 10:07 ` Dani Moncayo
2014-11-29 10:32 ` Eli Zaretskii
2014-11-29 18:22 ` Dani Moncayo
2014-11-29 18:31 ` Eli Zaretskii
2014-11-29 19:25 ` Dani Moncayo
2014-11-29 20:23 ` Eli Zaretskii
2014-11-29 20:37 ` Dani Moncayo
2014-11-29 20:52 ` Eli Zaretskii
2014-11-29 16:24 ` Óscar Fuentes
2014-11-29 18:37 ` Dani Moncayo
2014-11-29 18:49 ` Eli Zaretskii
2014-11-29 19:23 ` Dani Moncayo
2014-11-29 19:33 ` Achim Gratz
2014-11-29 19:41 ` Andreas Schwab
2014-11-29 19:45 ` Óscar Fuentes
2014-11-29 20:21 ` Eli Zaretskii
2014-11-25 23:42 ` Dani Moncayo
2014-11-22 8:46 ` Dani Moncayo
2014-11-22 10:16 ` Eli Zaretskii
2014-11-22 15:11 ` Óscar Fuentes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87egsrnguj.fsf@wanadoo.es \
--to=ofv@wanadoo.es \
--cc=19111@debbugs.gnu.org \
--cc=dmoncayo@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.