* bug#9713: emacs 24.0.90 alloc.c assertion failure
@ 2011-10-10 0:21 Karl Berry
2011-10-10 5:45 ` Eli Zaretskii
[not found] ` <50158261@toto.iv>
0 siblings, 2 replies; 14+ messages in thread
From: Karl Berry @ 2011-10-10 0:21 UTC (permalink / raw)
To: 9713
(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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9713: emacs 24.0.90 alloc.c assertion failure
2011-10-10 0:21 bug#9713: emacs 24.0.90 alloc.c assertion failure Karl Berry
@ 2011-10-10 5:45 ` Eli Zaretskii
2011-10-10 18:28 ` Glenn Morris
[not found] ` <50158261@toto.iv>
1 sibling, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2011-10-10 5:45 UTC (permalink / raw)
To: Karl Berry; +Cc: 9713
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9713: emacs 24.0.90 alloc.c assertion failure
2011-10-10 5:45 ` Eli Zaretskii
@ 2011-10-10 18:28 ` Glenn Morris
2011-10-11 17:55 ` Karl Berry
0 siblings, 1 reply; 14+ messages in thread
From: Glenn Morris @ 2011-10-10 18:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 9713, Karl Berry
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9713: emacs 24.0.90 alloc.c assertion failure
2011-10-10 18:28 ` Glenn Morris
@ 2011-10-11 17:55 ` Karl Berry
2011-10-11 19:29 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Karl Berry @ 2011-10-11 17:55 UTC (permalink / raw)
To: rgm; +Cc: 9713
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9713: emacs 24.0.90 alloc.c assertion failure
2011-10-11 17:55 ` Karl Berry
@ 2011-10-11 19:29 ` Eli Zaretskii
2011-10-11 20:17 ` Glenn Morris
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2011-10-11 19:29 UTC (permalink / raw)
To: Karl Berry; +Cc: 9713
> 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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9713: emacs 24.0.90 alloc.c assertion failure
2011-10-11 19:29 ` Eli Zaretskii
@ 2011-10-11 20:17 ` Glenn Morris
2011-10-11 22:07 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Glenn Morris @ 2011-10-11 20:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 9713, Karl Berry
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='#'
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9713: emacs 24.0.90 alloc.c assertion failure
2011-10-11 20:17 ` Glenn Morris
@ 2011-10-11 22:07 ` Eli Zaretskii
2011-10-11 22:13 ` Karl Berry
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2011-10-11 22:07 UTC (permalink / raw)
To: Glenn Morris; +Cc: 9713, karl
> 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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9713: emacs 24.0.90 alloc.c assertion failure
2011-10-11 22:07 ` Eli Zaretskii
@ 2011-10-11 22:13 ` Karl Berry
2011-10-11 23:09 ` Glenn Morris
0 siblings, 1 reply; 14+ messages in thread
From: Karl Berry @ 2011-10-11 22:13 UTC (permalink / raw)
To: 9713
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9713: emacs 24.0.90 alloc.c assertion failure
2011-10-11 22:13 ` Karl Berry
@ 2011-10-11 23:09 ` Glenn Morris
0 siblings, 0 replies; 14+ messages in thread
From: Glenn Morris @ 2011-10-11 23:09 UTC (permalink / raw)
To: 9713
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/.)
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9713: stdint.h in emacs
[not found] <201110112128.p9BLSaTO031532@freefriends.org>
@ 2011-10-11 23:29 ` Paul Eggert
0 siblings, 0 replies; 14+ messages in thread
From: Paul Eggert @ 2011-10-11 23:29 UTC (permalink / raw)
To: Karl Berry; +Cc: 9713
I can't reproduce the problem on CentOS 5.7 x86-64
when using 'gcc -m32'. This is the system GCC,
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51). I configured
with "configure CC='gcc -m32' --with-x-toolkit=no -with-xpm=no"
(because I don't have those 32-bit libraries installed).
Could you please send in your config.log and src/config.h?
Compressed is fine.
My guess is that there's some problem with the setup that
causes compilation to fail subtly, bad enough so that both
the stdint.h test fails, and that gnulib's attempt to create
a substitute stdint.h also fails, the latter because 'configure'
can't determine the bit width of ptrdiff_t.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9713: stdint.h in emacs
[not found] ` <50158261@toto.iv>
@ 2011-10-11 23:52 ` Karl Berry
2011-10-12 0:13 ` Glenn Morris
2011-10-12 7:07 ` Paul Eggert
0 siblings, 2 replies; 14+ messages in thread
From: Karl Berry @ 2011-10-11 23:52 UTC (permalink / raw)
To: eggert; +Cc: 9713
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9713: stdint.h in emacs
2011-10-11 23:52 ` bug#9713: stdint.h in emacs Karl Berry
@ 2011-10-12 0:13 ` Glenn Morris
2011-10-13 18:54 ` Karl Berry
2011-10-12 7:07 ` Paul Eggert
1 sibling, 1 reply; 14+ messages in thread
From: Glenn Morris @ 2011-10-12 0:13 UTC (permalink / raw)
To: Karl Berry; +Cc: 9713, eggert
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9713: stdint.h in emacs
2011-10-11 23:52 ` bug#9713: stdint.h in emacs Karl Berry
2011-10-12 0:13 ` Glenn Morris
@ 2011-10-12 7:07 ` Paul Eggert
1 sibling, 0 replies; 14+ messages in thread
From: Paul Eggert @ 2011-10-12 7:07 UTC (permalink / raw)
To: Karl Berry; +Cc: 9713
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9713: stdint.h in emacs
2011-10-12 0:13 ` Glenn Morris
@ 2011-10-13 18:54 ` Karl Berry
0 siblings, 0 replies; 14+ messages in thread
From: Karl Berry @ 2011-10-13 18:54 UTC (permalink / raw)
To: 9713
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
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-10-13 18:54 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-10 0:21 bug#9713: emacs 24.0.90 alloc.c assertion failure Karl Berry
2011-10-10 5:45 ` Eli Zaretskii
2011-10-10 18:28 ` Glenn Morris
2011-10-11 17:55 ` Karl Berry
2011-10-11 19:29 ` Eli Zaretskii
2011-10-11 20:17 ` Glenn Morris
2011-10-11 22:07 ` Eli Zaretskii
2011-10-11 22:13 ` Karl Berry
2011-10-11 23:09 ` Glenn Morris
[not found] ` <50158261@toto.iv>
2011-10-11 23:52 ` bug#9713: stdint.h in emacs Karl Berry
2011-10-12 0:13 ` Glenn Morris
2011-10-13 18:54 ` Karl Berry
2011-10-12 7:07 ` Paul Eggert
[not found] <201110112128.p9BLSaTO031532@freefriends.org>
2011-10-11 23:29 ` Paul Eggert
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).