GNU bug report logs - #29620
configure fails when cross-compiling for the same architecture

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29620 in the body.
You can then email your comments to 29620 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org, eggert <at> cs.ucla.edu
Subject: configure fails when cross-compiling for the same architecture
Date: Sat, 9 Dec 2017 00:10:05 +0000

I tried building Paul's MPX patch on a CPU that doesn't support MPX,
so I could run the executable with Intel's CPU emulator. I used
./configure CFLAGS="-O2 -g3 -mmpx -fcheck-pointer-bounds", but that
failed because the executable produced by the tputs test cannot run
(natively) on my CPU.

It would be nice to have a configure option to specify that while
build and target machines share the same architecture, they don't
share the same -m flags, so that we're effectively cross-compiling. Is
this possible with autoconf?

Message #8 received at 29620 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 29620 <at> debbugs.gnu.org
Subject: Re: configure fails when cross-compiling for the same architecture
Date: Wed, 13 Dec 2017 11:44:19 -0800

[Sending again, as my earlier message was CC'ed to the wrong bug number.]

On 12/08/2017 04:10 PM, Pip Cet wrote:
> I tried building Paul's MPX patch on a CPU that doesn't support MPX,
> so I could run the executable with Intel's CPU emulator. I used
> ./configure CFLAGS="-O2 -g3 -mmpx -fcheck-pointer-bounds", but that
> failed because the executable produced by the tputs test cannot run
> (natively) on my CPU.

That's odd, since MPX instructions are supposed to be no-ops on non-MPX 
CPUs. "./configure CC='gcc -mmpx -fcheck-pointer-bounds' && make" works 
fine on Emacs master when I build it on my old non-MPX desktop running 
Fedora 27 x86-64. This is an AMD Phenom II X4 910e processor (circa 2010).

> It would be nice to have a configure option to specify that while
> build and target machines share the same architecture, they don't
> share the same -m flags, so that we're effectively cross-compiling. Is
> this possible with autoconf?

I would think that a cross-compiler-enabled configure script would work 
easily with that, as it shouldn't care how closely related the build and 
target machines are. However, the Emacs build procedure isn't designed 
to work in cross-compilation builds so I'm afraid that if you want to 
cross-compile you'll need to do it by hand (admittedly a daunting prospect).

Message #11 received at 29620 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 29620 <at> debbugs.gnu.org, Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#29620: configure fails when cross-compiling for the same
 architecture
Date: Mon, 10 Aug 2020 08:42:40 -0700

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> [Sending again, as my earlier message was CC'ed to the wrong bug number.]
>
> On 12/08/2017 04:10 PM, Pip Cet wrote:
>> I tried building Paul's MPX patch on a CPU that doesn't support MPX,
>> so I could run the executable with Intel's CPU emulator. I used
>> ./configure CFLAGS="-O2 -g3 -mmpx -fcheck-pointer-bounds", but that
>> failed because the executable produced by the tputs test cannot run
>> (natively) on my CPU.
>
> That's odd, since MPX instructions are supposed to be no-ops on non-MPX
> CPUs. "./configure CC='gcc -mmpx -fcheck-pointer-bounds' && make" works
> fine on Emacs master when I build it on my old non-MPX desktop running Fedora 27
> x86-64. This is an AMD Phenom II X4 910e processor (circa 2010).
>
>> It would be nice to have a configure option to specify that while
>> build and target machines share the same architecture, they don't
>> share the same -m flags, so that we're effectively cross-compiling. Is
>> this possible with autoconf?
>
> I would think that a cross-compiler-enabled configure script would work easily
> with that, as it shouldn't care how closely related the build and target
> machines are. However, the Emacs build procedure isn't designed to work in
> cross-compilation builds so I'm afraid that if you want to cross-compile you'll
> need to do it by hand (admittedly a daunting prospect).

No update here within two and a half years.  From reading the bug
report, it is not clear to me if there is more to do here or not.

(No support for cross-compilation is a known issue tracked in
e.g. Bug#9192.)

So should this be closed?

Best regards,
Stefan Kangas

Message #16 received at 29620-done <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 29620-done <at> debbugs.gnu.org
Subject: Re: bug#29620: configure fails when cross-compiling for the same
 architecture
Date: Mon, 10 Aug 2020 15:44:09 +0000

On Mon, Aug 10, 2020 at 3:42 PM Stefan Kangas <stefan <at> marxist.se> wrote:
> So should this be closed?

Yes, thanks!

Message #19 received at 29620-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 29620-done <at> debbugs.gnu.org, Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#29620: configure fails when cross-compiling for the same
 architecture
Date: Tue, 11 Aug 2020 02:39:53 -0700

On 8/10/20 8:42 AM, Stefan Kangas wrote:

> No update here within two and a half years.  From reading the bug
> report, it is not clear to me if there is more to do here or not.

The need prompting the original bug report is gone now that MPX support has been 
removed from Emacs.

The more-general problem probably remains, but the need is relatively low (as 
evidenced by no discussion for years) so I'll take the liberty of closing this 
bug report. We can always reopen it later, or file a new bug report, or whatever.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.