bug#9713: stdint.h in emacs

bug#9713: stdint.h in emacs

[Paul Eggert]

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.

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