bug#11669: 24.1; Build failure on amd64 with x32 ABI

bug#11669: 24.1; Build failure on amd64 with x32 ABI

[Ulrich Mueller]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 1246 bytes --]

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

[-- Attachment #2: 03_all_x32.patch --]
[-- Type: text/plain, Size: 245 bytes --]

--- 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)

bug#11669: 24.1; Build failure on amd64 with x32 ABI

[Glenn Morris]

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?

bug#11669: 24.1; Build failure on amd64 with x32 ABI

[Glenn Morris]

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?

bug#11669: 24.1; Build failure on amd64 with x32 ABI

[Ulrich Mueller]

>>>>> 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?

bug#11669: 24.1; Build failure on amd64 with x32 ABI

[Glenn Morris]

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.

bug#11669: 24.1; Build failure on amd64 with x32 ABI

[Ulrich Mueller]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 347 bytes --]

> 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.)


[-- Attachment #2: emacs-24.1-x32.patch --]
[-- Type: text/plain, Size: 594 bytes --]

--- 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

bug#11669: 24.1; Build failure on amd64 with x32 ABI

[Glenn Morris]

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.

bug#11669: 24.1; Build failure on amd64 with x32 ABI

[Ulrich Mueller]

>>>>> 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.

bug#11669: 24.1; Build failure on amd64 with x32 ABI

[Glenn Morris]

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).