GNU bug report logs - #11669
24.1; Build failure on amd64 with x32 ABI

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 11669 in the body.
You can then email your comments to 11669 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: Ulrich Mueller <ulm <at> gentoo.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.1; Build failure on amd64 with x32 ABI
Date: Sun, 10 Jun 2012 21:42:20 +0200

[Message part 1 (text/plain, inline)]

Forwarding downstream bug: <https://bugs.gentoo.org/show_bug.cgi?id=420257>

Emacs 24.1 fails to build on an amd64 system with x32 ABI [1][2].
During compilation, about 20000 warnings like:

   warning: left shift count >= width of type [enabled by default]
   warning: right shift count >= width of type [enabled by default]

occur, and finally the build process aborts with a segmentation fault:

   if test "no" = "yes"; then \
     ln -f temacs bootstrap-emacs; \
   else \
     `/bin/pwd`/temacs --batch --load loadup bootstrap || exit 1; \
     test "X" = X ||  -zex emacs; \
     mv -f emacs bootstrap-emacs; \
   fi
   /bin/sh: line 6: 27446 Segmentation fault      `/bin/pwd`/temacs --batch --load loadup bootstrap
   make[1]: *** [bootstrap-emacs] Error 1
   make[1]: Leaving directory `/var/tmp/portage/app-editors/emacs-24.1/work/emacs-24.1/src'
   make: *** [src] Error 2

See [3] for the full build log.

I've attached a one line patch that fixes the problem for me.
AFAICS, Emacs from BZR is not affected.

(Sorry about the bad timing, but x32 support in Gentoo is just
available since a few days.)

[1] https://lwn.net/Articles/500482/
[2] https://sites.google.com/site/x32abi/
[3] http://dev.gentoo.org/~ulm/emacs-24.1-build.log

[03_all_x32.patch (text/plain, inline)]

--- emacs-24.1-orig/configure.in
+++ emacs-24.1/configure.in
@@ -749,6 +749,7 @@
     machine=intel386
     machfile="m/${machine}.h"
   fi
+  AC_CHECK_DECL([__ILP32__], [machfile="m/intel386.h"])
 fi
 
 AC_PATH_PROG(INSTALL_INFO, install-info)

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

From: Glenn Morris <rgm <at> gnu.org>
To: Ulrich Mueller <ulm <at> gentoo.org>
Cc: 11669 <at> debbugs.gnu.org
Subject: Re: bug#11669: 24.1; Build failure on amd64 with x32 ABI
Date: Mon, 11 Jun 2012 02:46:00 -0400

Ulrich Mueller wrote:

> +  AC_CHECK_DECL([__ILP32__], [machfile="m/intel386.h"])

emacs-24's configure.in already attempts to deal with this kind of
thing:

## Although we're running on an amd64 kernel, we're actually compiling for
## the x86 architecture.  The user should probably have provided an
## explicit --build to `configure', but if everything else than the kernel
## is running in i386 mode, we can help them out.
if test "$machine" = "amdx86-64"; then
  AC_CHECK_DECL([i386])
  if test "$ac_cv_have_decl_i386" = "yes"; then
    canonical=`echo "$canonical" | sed -e 's/^amd64/i386/' -e 's/^x86_64/i386/'`
    machine=intel386
    machfile="m/${machine}.h"
  fi
fi


So I guess you don't define i386 but rather __ILP32__ for some reason?


However, the src/m files have been removed in the trunk and the above
piece of configure with it.

http://lists.gnu.org/archive/html/emacs-diffs/2012-05/msg00352.html

I don't know what, if anything, replaces it.

Is passing an explicit --build to configure now the recommended/only way
to deal with this?

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

From: Glenn Morris <rgm <at> gnu.org>
To: Ulrich Mueller <ulm <at> gentoo.org>
Cc: 11669 <at> debbugs.gnu.org
Subject: Re: bug#11669: 24.1; Build failure on amd64 with x32 ABI
Date: Mon, 11 Jun 2012 14:30:18 -0400

Glenn Morris wrote:

> emacs-24's configure.in already attempts to deal with this kind of
> thing:

I didn't look at the context of your patch; obviously you knew that.

I wonder if the removal of src/m/ in the trunk means it Just Works now?

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

From: Ulrich Mueller <ulm <at> gentoo.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 11669 <at> debbugs.gnu.org
Subject: Re: bug#11669: 24.1; Build failure on amd64 with x32 ABI
Date: Mon, 11 Jun 2012 22:27:53 +0200

>>>>> On Mon, 11 Jun 2012, Glenn Morris wrote:

> So I guess you don't define i386 but rather __ILP32__ for some
> reason?

For x32, GCC defines both __x86_64__ and __ILP32__ (but not i386).
And the canonical system name is x86_64-pc-linux-gnu.

Size of long and of pointers is the same between i386 and x32.
However, x32 has native 64 bit support, so programs will get access to
64 bit registers for 64 bit types (e.g., long long).

> However, the src/m files have been removed in the trunk and the
> above piece of configure with it.

>>>>> On Mon, 11 Jun 2012, Glenn Morris wrote:

>> emacs-24's configure.in already attempts to deal with this kind of
>> thing:

> I didn't look at the context of your patch; obviously you knew that.

> I wonder if the removal of src/m/ in the trunk means it Just Works
> now?

Right, I haven't noticed any problems with the trunk.

Will 24.2 be released from the trunk or from the emacs-24 branch?

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

From: Glenn Morris <rgm <at> gnu.org>
To: Ulrich Mueller <ulm <at> gentoo.org>
Cc: 11669 <at> debbugs.gnu.org
Subject: Re: bug#11669: 24.1; Build failure on amd64 with x32 ABI
Date: Mon, 11 Jun 2012 16:52:42 -0400

Ulrich Mueller wrote:

>> I wonder if the removal of src/m/ in the trunk means it Just Works
>> now?
>
> Right, I haven't noticed any problems with the trunk.
>
> Will 24.2 be released from the trunk or from the emacs-24 branch?

Effectively from trunk unless something unexpected happens.
emacs-24 should get some form of band-aid "do not merge to trunk" fix
for this, just in case.

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

From: Ulrich Mueller <ulm <at> gentoo.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 11669 <at> debbugs.gnu.org
Subject: Re: bug#11669: 24.1; Build failure on amd64 with x32 ABI
Date: Fri, 15 Jun 2012 08:21:56 +0200

[Message part 1 (text/plain, inline)]

> emacs-24 should get some form of band-aid "do not merge to trunk"
> fix for this, just in case.

I've now applied a somewhat different solution to the Gentoo package,
namely patching the m/amdx86-64.h file, see attached patch. (This
should also ensure that it isn't accidentally merged to trunk, because
the file doesn't exist there any more.)

[emacs-24.1-x32.patch (text/plain, inline)]

--- emacs-24.1-orig/src/m/amdx86-64.h
+++ emacs-24.1/src/m/amdx86-64.h
@@ -17,6 +17,7 @@
 You should have received a copy of the GNU General Public License
 along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
 
+#ifndef __ILP32__               /* Don't define for x32 ABI.  */
 #define BITS_PER_LONG           64
 #define BITS_PER_EMACS_INT      64
 
@@ -30,6 +31,7 @@
 #define EMACS_INT               long
 #define pI			"l"
 #define EMACS_UINT              unsigned long
+#endif /* __ILP32__ */
 
 /* Define XPNTR to avoid or'ing with DATA_SEG_BITS */
 #undef DATA_SEG_BITS

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

From: Glenn Morris <rgm <at> gnu.org>
To: Ulrich Mueller <ulm <at> gentoo.org>
Cc: 11669 <at> debbugs.gnu.org
Subject: Re: bug#11669: 24.1; Build failure on amd64 with x32 ABI
Date: Thu, 21 Jun 2012 03:13:07 -0400

Ulrich Mueller wrote:

> I've now applied a somewhat different solution to the Gentoo package,
> namely patching the m/amdx86-64.h file, see attached patch. (This
> should also ensure that it isn't accidentally merged to trunk, because
> the file doesn't exist there any more.)

The two patches don't (?) seem to be equivalent (wrt DATA_SEG_BITS and
ULIMIT_BREAK_VALUE).

I'd prefer to install the configure one, since it is more consistent
with previous treatments. Unless there is some reason to prefer the
other one? Accidental merging to trunk is not an issue.

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

From: Ulrich Mueller <ulm <at> gentoo.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 11669 <at> debbugs.gnu.org
Subject: Re: bug#11669: 24.1; Build failure on amd64 with x32 ABI
Date: Thu, 21 Jun 2012 21:36:28 +0200

>>>>> On Thu, 21 Jun 2012, Glenn Morris wrote:

>> I've now applied a somewhat different solution to the Gentoo
>> package, namely patching the m/amdx86-64.h file, see attached
>> patch.

> The two patches don't (?) seem to be equivalent (wrt DATA_SEG_BITS
> and ULIMIT_BREAK_VALUE).

There's an #undef DATA_SEG_BITS in m/amdx86-64.h, but DATA_SEG_BITS
isn't defined at that point, in the first place. (It's only being
defined in some machine and system files like HPUX and IRIX that are
not relevant for our case.)

Concerning ULIMIT_BREAK_VALUE: This is used only in vm-limit.c.
However, the branch of the code where it is used isn't reached for
modern GNU/Linux systems, because for these both HAVE_GETRLIMIT and
RLIMIT_AS should be defined.

(And I wonder if is even possible to run a recent Emacs with an
address space limited to 32 MiB, as the ULIMIT_BREAK_VALUE of
32*1024*1024 suggests? This looks like a relic from the early 1990s
to me.)

> I'd prefer to install the configure one, since it is more consistent
> with previous treatments. Unless there is some reason to prefer the
> other one? Accidental merging to trunk is not an issue.

*shrug* I don't have a strong preference. Patching the machine file
looked slightly more systematic to me, because x32 really isn't
intel386.

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

From: Glenn Morris <rgm <at> gnu.org>
To: 11669-done <at> debbugs.gnu.org
Subject: Re: bug#11669: 24.1; Build failure on amd64 with x32 ABI
Date: Thu, 21 Jun 2012 15:44:19 -0400

Version: 24.2

OK, I applied the configure version to the emacs-24 branch marked "do
not merge to trunk". It should be academic anyway since at the moment it
does not look like 24.2 will come from there (effectively).

Previous Next

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