bug#9713: emacs 24.0.90 alloc.c assertion failure

bug#9713: emacs 24.0.90 alloc.c assertion failure

[Karl Berry]

(If there's a different place to report pretest bugs, please inform.
Saw nothing in the README.)

Trying to compile the emacs 24.0.90 pretest on (the latest) CentOS 5.7,
the assertion at line 740 of alloc.c fails:
verify (INT_MAX <= PTRDIFF_MAX);

With the system compiler (gcc version 4.1.2 20080704 (Red Hat 4.1.2-51)),
the error is;
alloc.c:740: error: negative width in bit-field '_gl_verify_error_if_negative'

With gcc 4.6.1 compiled from the original sources, the error is:
alloc.c:740:1: error: static assertion failed: "verify (INT_MAX <= PTRDIFF_MAX)"


I tried removing the verify() call, just to see.  Unfortunately, then
temacs either got a segmentation fault (system compiler) or failed to
link with multiple definitions of g_bit_nth_lsf and many more g_bit_*
functions (4.6.1).

karl

bug#9713: emacs 24.0.90 alloc.c assertion failure

[Eli Zaretskii]

> Date: Mon, 10 Oct 2011 00:21:23 GMT
> From: karl@freefriends.org (Karl Berry)
> 
> (If there's a different place to report pretest bugs, please inform.
> Saw nothing in the README.)

This is the right place.  "M-x report-emacs-bug RET" does TRT
automagically.

> Trying to compile the emacs 24.0.90 pretest on (the latest) CentOS 5.7,
> the assertion at line 740 of alloc.c fails:
> verify (INT_MAX <= PTRDIFF_MAX);
> 
> With the system compiler (gcc version 4.1.2 20080704 (Red Hat 4.1.2-51)),
> the error is;
> alloc.c:740: error: negative width in bit-field '_gl_verify_error_if_negative'
> 
> With gcc 4.6.1 compiled from the original sources, the error is:
> alloc.c:740:1: error: static assertion failed: "verify (INT_MAX <= PTRDIFF_MAX)"

What are INT_MAX and PTRDIFF_MAX on that machine?  IOW, first let's
see if this is a false alarm or not.

bug#9713: emacs 24.0.90 alloc.c assertion failure

[Glenn Morris]

FWIW, I had no problems compiling on x86_64 Scientific Linux 5.7 (which
should be identical to CentOS 5.7 for almost all purposes) using either
the default "gcc 4.1.2 20080704 (Red Hat 4.1.2-51)", or the optional
gcc44 package, which provides "gcc44 (GCC) 4.4.4 20100726 (Red Hat 4.4.4-13)".

The system has

limits.h:
# define INT_MAX      2147483647

stdint.h:
# if __WORDSIZE == 64
#  define PTRDIFF_MIN       (-9223372036854775807L-1)
#  define PTRDIFF_MAX           (9223372036854775807L)
# else
#  define PTRDIFF_MIN       (-2147483647-1)
#  define PTRDIFF_MAX           (2147483647)
# endif

bug#9713: emacs 24.0.90 alloc.c assertion failure

[Karl Berry]

    x86_64 Scientific Linux 5.7

I am compiling on 32-bit, not 64-bit.  Perhaps that is the difference.

    The system has

I have exactly those same values in the same headers.  However, running
gcc -dD -E on alloc.c (after configuration, with all the same args as
used for compilation) shows that those values are not being used.

Instead, Emacs's (gnulib's) lib/stdint.h is being used (why?), which
unconditionally redefines PTRDIFF_MAX as _STDINT_MAX, which is defined
in that same file as the RHS here (the LHS is the recognizable value of
INT_MAX):

_Static_assert (2147483647 <= ((1) ? ~ ((1) ? (- ((0) + 1) << ((0) ? (0) - 1 : 0)) : (0)) : ((((0) + 1) << ((0) ? (0) - 1 - (1) : 0)) - 1) * 2 + 1), "verify (" "INT_MAX <= PTRDIFF_MAX" ")");


FWIW, if I reduce the input file to these four lines:
#include <config.h>
#include "lisp.h"
#include <verify.h>
verify (INT_MAX <= PTRDIFF_MAX);

And compile with all the same options, I get the same error from verify
(along with a spurious error about jmp_buf).  Without "lisp.h",
PTRDIFF_MAX is not defined.

Here is my full command line:
gcc -std=gnu99 -c -Demacs -DHAVE_CONFIG_H \
-I. -I/usr/local/gnu/src/emacs-24.0.90/src -I../lib \
-I/usr/local/gnu/src/emacs-24.0.90/src/../lib   -I/usr/include/gtk-2.0 \
-I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo \
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0 \
-I/usr/lib/glib-2.0/include -I/usr/include/freetype2 \
-I/usr/include/libpng12   -I/usr/include/freetype2 \
-I/usr/include/alsa   -I/usr/include/librsvg-2 -I/usr/include/glib-2.0 \
-I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 \
-I/usr/include/libxml2   -I/usr/include/dbus-1.0 \
-I/usr/lib/dbus-1.0/include   -DORBIT2=1 -pthread -I/usr/include/gconf/2 \
-I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 \
-I/usr/lib/glib-2.0/include   -I/usr/include/freetype2      -MMD -MF \
deps/alloc.d -MP   -Wimplicit-function-declaration \
-Wold-style-definition -Wdeclaration-after-statement  -g -O2 alloc.c


karl

bug#9713: emacs 24.0.90 alloc.c assertion failure

[Eli Zaretskii]

> Date: Tue, 11 Oct 2011 17:55:11 GMT
> From: karl@freefriends.org (Karl Berry)
> Cc: eliz@gnu.org, 9713@debbugs.gnu.org
> 
> I have exactly those same values in the same headers.  However, running
> gcc -dD -E on alloc.c (after configuration, with all the same args as
> used for compilation) shows that those values are not being used.
> 
> Instead, Emacs's (gnulib's) lib/stdint.h is being used (why?), which
> unconditionally redefines PTRDIFF_MAX as _STDINT_MAX, which is defined
> in that same file as the RHS here (the LHS is the recognizable value of
> INT_MAX):
> 
> _Static_assert (2147483647 <= ((1) ? ~ ((1) ? (- ((0) + 1) << ((0) ? (0) - 1 : 0)) : (0)) : ((((0) + 1) << ((0) ? (0) - 1 - (1) : 0)) - 1) * 2 + 1), "verify (" "INT_MAX <= PTRDIFF_MAX" ")");
> 
> 
> FWIW, if I reduce the input file to these four lines:
> #include <config.h>
> #include "lisp.h"
> #include <verify.h>
> verify (INT_MAX <= PTRDIFF_MAX);
> 
> And compile with all the same options, I get the same error from verify
> (along with a spurious error about jmp_buf).  Without "lisp.h",
> PTRDIFF_MAX is not defined.

So I think this is the culprit.  Glenn, I guess your system also uses
lib/stdint.h, right?  So what is different?

bug#9713: emacs 24.0.90 alloc.c assertion failure

[Glenn Morris]

Eli Zaretskii wrote:

> So I think this is the culprit.  Glenn, I guess your system also uses
> lib/stdint.h, right?

Nope. I have no lib/stdint.h, only lib/stdint.h.in.

config.log says:
configure:6345: checking for stdint.h
configure:6345: gcc -c -g -O2  conftest.c >&5
configure:6345: $? = 0
configure:6345: result: yes
[...]
GL_GENERATE_STDINT_H_FALSE=''
GL_GENERATE_STDINT_H_TRUE='#'

bug#9713: emacs 24.0.90 alloc.c assertion failure

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: karl@freefriends.org (Karl Berry),  9713@debbugs.gnu.org
> Date: Tue, 11 Oct 2011 16:17:09 -0400
> 
> Eli Zaretskii wrote:
> 
> > So I think this is the culprit.  Glenn, I guess your system also uses
> > lib/stdint.h, right?
> 
> Nope. I have no lib/stdint.h, only lib/stdint.h.in.

Right, I see the same on fencepost.

So, Karl, can you find out why your system stdint.h is not used?

bug#9713: emacs 24.0.90 alloc.c assertion failure

[Karl Berry]

    Right, I see the same on fencepost.

fp is also a 64-bit system, says uname -a.

    So, Karl, can you find out why your system stdint.h is not used?

I can, with enough work, but the point is, there is evidently a bug in
the gnulib stdint.h in Emacs.  I asked Paul (Eggert) about it.

bug#9713: emacs 24.0.90 alloc.c assertion failure

[Glenn Morris]

Karl Berry wrote:

> fp is also a 64-bit system, says uname -a.

For the record, it also builds fine for me on 32-bit RHEL5.7.
(Again the system stdint.h is used, not that from lib/.)

bug#9713: stdint.h in emacs

[Karl Berry]

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

Hi Paul,

    I can't reproduce the problem on CentOS 5.7 x86-64

Sigh.  If you need access to a real 32-bit system, let me know.

    gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51).  

That is my /usr/bin/gcc -version as well.  I ran this stuff with 
PATH=/bin:/usr/bin.

    with "configure CC='gcc -m32' --with-x-toolkit=no -with-xpm=no"

I omitted the CC=, and added --with-gif=no since I don't have that
library.

    Could you please send in your config.log and src/config.h?

Attached, along with the transcript of the configure (conf.out) and make
(make.out) runs, just in case.

I surmise gnulib thinks my system stdint.h is insufficient due to:
  checking whether stdint.h conforms to C99... no

Does Emacs require C99 now?  I didn't think so.  And then there is:
  checking for bit size of ptrdiff_t... unknown
which doesn't seem right ...

Thanks,
karl


[-- Attachment #2: config.log.gz --]
[-- Type: application/octet-stream, Size: 37374 bytes --]

[-- Attachment #3: config.h.gz --]
[-- Type: application/octet-stream, Size: 11225 bytes --]

[-- Attachment #4: conf.out.gz --]
[-- Type: application/octet-stream, Size: 4621 bytes --]

[-- Attachment #5: make.out.gz --]
[-- Type: application/octet-stream, Size: 6245 bytes --]

bug#9713: stdint.h in emacs

[Glenn Morris]

You've got this a lot in config.log:

./conftest: error while loading shared libraries: libintl.so.1: cannot
open shared object file: No such file or directory

which causes a bunch of tests to fail.

Looks like -lintl gets added to the list of libraries through

 # Solaris requires -lintl if you want strerror (which calls dgettext)
 # to return localized messages.
 AC_CHECK_LIB(intl, dgettext)


configure:15285: checking for dgettext in -lintl
configure:15310: gcc -std=gnu99 -o conftest  -g -O2
-I/usr/include/librsvg-2 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0
-I/usr/include/freetype2       -I/usr/include/freetype2
-Wl,-znocombreloc  conftest.c -lintl  -lncurses -lm -lxml2 -lz -lm
-lSM -lICE -lXrender -lXft -lXrender -lfontconfig -lfreetype -lX11
-L/lib -lrsvg-2 -lgdk_pixbuf-2.0 -lm -lgobject-2.0 -lgmodule-2.0 -ldl
-lglib-2.0   -lX11   -L/lib -ldbus-1   >&5 
conftest.c:200: warning: conflicting types for built-in function 'dgettext'
configure:15310: $? = 0
configure:15319: result: yes

On my system, that fails with

/usr/bin/ld: cannot find -lintl
collect2: ld returned 1 exit status

bug#9713: stdint.h in emacs

[Paul Eggert]

On 10/11/11 16:52, Karl Berry wrote:

> I surmise gnulib thinks my system stdint.h is insufficient due to:
>   checking whether stdint.h conforms to C99... no

Yes.  But I think Glenn found the underlying problem: the addition of
-lintl was causing lots of later 'configure' tests to mess up, including
the test for stdint.h and the test for ptrdiff_t.

> Does Emacs require C99 now?  I didn't think so.

That's right.  Emacs uses a few C99 features if available, but does
not require them.

I installed the following patch into the trunk as bzr 106063.  You can try
it now if you use the trunk directly, or can try it with the next pretest
snapshot when that becomes available, or if you're adventurous you can
apply it to your pretest copy and run "autoreconf -I m4" to propagate
it into 'configure'.  Please let us know how it goes.  And thanks for
reporting the problem.

=== modified file 'ChangeLog'
--- ChangeLog	2011-10-07 21:15:00 +0000
+++ ChangeLog	2011-10-12 06:56:23 +0000
@@ -1,3 +1,12 @@
+2011-10-12  Paul Eggert  <eggert@cs.ucla.edu>
+
+	* configure.in: Remove check for -lintl (Bug#9713).
+	The check breaks 'configure' in some CentOS 5.7 x86 configurations.
+	The check was helpful but not essential in Solaris 2.6 (1997),
+	and is no longer needed in Solaris 8 (2000).  Solaris 2.6 is
+	obsolete -- Sun dropped support for it in 2006 -- and without
+	access to that Silurian platform we can't maintain the code anyway.
+
 2011-10-07  Paul Eggert  <eggert@cs.ucla.edu>
 
 	Merge from gnulib, fixing some 'configure' typos (Bug#9696).

=== modified file 'configure.in'
--- configure.in	2011-10-07 07:23:44 +0000
+++ configure.in	2011-10-12 06:56:23 +0000
@@ -3008,10 +3008,6 @@
 AC_SUBST(DESLIB)
 AC_SUBST(KRB4LIB)
 
-# Solaris requires -lintl if you want strerror (which calls dgettext)
-# to return localized messages.
-AC_CHECK_LIB(intl, dgettext)
-
 AC_MSG_CHECKING(whether localtime caches TZ)
 AC_CACHE_VAL(emacs_cv_localtime_cache,
 [if test x$ac_cv_func_tzset = xyes; then

bug#9713: stdint.h in emacs

[Karl Berry]

    On my system, that fails with
    /usr/bin/ld: cannot find -lintl

Seems that's what I should have been getting too.  The only
libintl-related thing I see in the system directories in
/usr/lib/preloadable_libintl.so, which I hope would not count as -lintl.

Experimentally, it seems the system ld was somehow finding an old
libintl I had compiled myself years ago, installed in an out-of-the-way
place (certainly not in the /usr/lib/gcc/i386-redhat-linux/4.1.2 or
/usr/lib directories mentioned by gcc -v).  How the *system* loader
(collect2) was finding it, I could not determine.  My local directory
wasn't in ld.so.conf or related.

Regardless, it seems like a good thing not to be checking for it these
days.

In any event, I just edited the configure script to omit the libintl
check, and the whole emacs build went fine.

So ... sorry for the noise, and this can be closed, if it isn't already.

Thanks,
karl