bug-m4
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: m4-1.4.12 configure message with report request


From: Eric Blake
Subject: Re: m4-1.4.12 configure message with report request
Date: Sat, 10 Jan 2009 16:08:39 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[please keep the list in the loop]

According to elio on 1/10/2009 2:32 PM:
>>> checking sys/timeb.h usability... no
>>> checking sys/timeb.h presence... yes
>>> configure: WARNING: sys/timeb.h: present but cannot be compiled
>>>     
>>
>> Can you isolate the portions of the config.log that mention why the
>> compilation failed (or send the entire config.log)?

Thanks for the config.log (and in this case, off-list made sense since it
was so large uncompressed).

> Hi, the file config.log is here (4.12 and 4.13).
> Configure close with warning but without errors.
> My actual version of m4 is 1.4.2. Similar problem in my machine is
> already with configure gzip 1.3.12 and tar 1.20.

Your installed versions of m4, gzip, and tar shouldn't matter much; if you
were able to successfully untar and unzip the files, then those two
programs are working, and m4 is not used during the configure phase
(bootstrapping m4 from a git checkout is a different matter, but tarballs
are immune to those considerations).

> 
> The errors with GNU make (3.81 just compiled):
> 
> In file included from gl_oset.h:22,
> from gl_avltree_oset.h:21,
> from gl_avltree_oset.c:21:
> /usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/include/stddef.h:214: error:
> duplicate ‘unsigned’
> /usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/include/stddef.h:214: error:
> two or more data types in declaration specifiers

So it looks like an instance where some header that got included before
<stddef.h> has a gnulib override that didn't fully account for system
include ordering issues.

>>
>> Also, could you please check if you still get these errors with the
>> latest
>> snapshot?  http://lists.gnu.org/archive/html/bug-m4/2008-12/msg00021.html

This would still be nice to know.  We've made some changes since m4 4.12
was released to the gnulib headers, so it may already fix your issue.

At any rate, here's the snippet from your config.log related to the
problems with sys/timeb.h:

configure:13823: checking sys/timeb.h usability
configure:13823: gcc -std=gnu99 -c -g -O2  conftest.c >&5
In file included from /usr/include/stdio.h:34,
                 from conftest.c:126:
/usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/include/stddef.h:214: error:
duplicat
e 'unsigned'
/usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/include/stddef.h:214: error:
two or m
ore data types in declaration specifiers
In file included from /usr/include/inttypes.h:28,
                 from conftest.c:151:
/usr/include/stdint.h:139: error: 'long long long' is too long for GCC
/usr/include/stdint.h:139: error: 'long long long' is too long for GCC
configure:13823: $? = 1
configure: failed program was:
| /* confdefs.h */
...
| #define __EXTENSIONS__ 1
| #define _ALL_SOURCE 1
| #define _GNU_SOURCE 1
...
| #define restrict __restrict
...
| #define _FILE_OFFSET_BITS 64
...
| #define HAVE_WCHAR_T 1
| #define HAVE_WINT_T 1
| #define size_t unsigned int
| #define intmax_t long long
...
| /* end confdefs.h.  */
| #include <stdio.h>
| #ifdef HAVE_SYS_TYPES_H
| # include <sys/types.h>
| #endif
| #ifdef HAVE_SYS_STAT_H
| # include <sys/stat.h>
| #endif
| #ifdef STDC_HEADERS
| # include <stdlib.h>
| # include <stddef.h>
| #else
| # ifdef HAVE_STDLIB_H
| #  include <stdlib.h>
| # endif
| #endif
| #ifdef HAVE_STRING_H
| # if !defined STDC_HEADERS && defined HAVE_MEMORY_H
| #  include <memory.h>
| # endif
| # include <string.h>
| #endif
| #ifdef HAVE_STRINGS_H
| # include <strings.h>
| #endif
| #ifdef HAVE_INTTYPES_H
| # include <inttypes.h>
| #endif
| #ifdef HAVE_STDINT_H
| # include <stdint.h>
| #endif
| #ifdef HAVE_UNISTD_H
| # include <unistd.h>
| #endif
| #include <sys/timeb.h>

Note that we've already defined intmax_t to 'long long' by this point in
the configure, so something even earlier is going wrong.  For that matter,
the first suspicious error in your log was:

configure:10246: checking whether snprintf is declared
configure:10246: gcc -std=gnu99 -c -g -O2  conftest.c >&5
/tmp/ccnjqmZ9.s: Assembler messages:
/tmp/ccnjqmZ9.s:1617: Error: symbol `fstat64' is already defined
/tmp/ccnjqmZ9.s:1642: Error: symbol `lstat64' is already defined
/tmp/ccnjqmZ9.s:1667: Error: symbol `stat64' is already defined
configure:10246: $? = 1
configure: failed program was:
...
| #include <stdio.h>
| #ifdef HAVE_SYS_TYPES_H
| # include <sys/types.h>
| #endif
| #ifdef HAVE_SYS_STAT_H
| # include <sys/stat.h>
| #endif
| #ifdef STDC_HEADERS
| # include <stdlib.h>
| # include <stddef.h>
| #else
| # ifdef HAVE_STDLIB_H
| #  include <stdlib.h>
| # endif
| #endif
| #ifdef HAVE_STRING_H
| # if !defined STDC_HEADERS && defined HAVE_MEMORY_H
| #  include <memory.h>
| # endif
| # include <string.h>
| #endif
| #ifdef HAVE_STRINGS_H
| # include <strings.h>
| #endif
| #ifdef HAVE_INTTYPES_H
| # include <inttypes.h>
| #endif
| #ifdef HAVE_STDINT_H
| # include <stdint.h>
| #endif
| #ifdef HAVE_UNISTD_H
| # include <unistd.h>
| #endif
| int
| main ()
| {
| #ifndef snprintf
|   (void) snprintf;
| #endif
|
|   ;
|   return 0;
| }


where I don't even see why the assembler would be confused by multiple
stat64 entries.  Or maybe this is another case of using too new of a gcc
with too old of glibc headers; there is a known glibc bug (since fixed)
where the headers do not work with newer gcc due to the gcc change in
inline semantics to comply with C99.
http://lists.gnu.org/archive/html/bug-gnulib/2008-12/msg00268.html

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklpKncACgkQ84KuGfSFAYC3IQCgkwFSHqTPk8g2MTCbMVLZeYvk
3vIAoJbSQATp3sg9e9vggv0LLxWmWnRI
=u3Yw
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]