Re: regex.c not 64-bit clean (?)
[EMAIL PROTECTED] (Eric Blake) writes: Bruno, is it okay to apply this? 2006-06-14 Eric Blake [EMAIL PROTECTED] * ssize_t.m4 (gt_TYPE_SSIZE_T): Work in spite of -Werror. I'm not Bruno, but yes, please apply that. Thanks.
Re: regex.c not 64-bit clean (?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 6/15/2006 1:32 AM: [EMAIL PROTECTED] (Eric Blake) writes: Bruno, is it okay to apply this? 2006-06-14 Eric Blake [EMAIL PROTECTED] * ssize_t.m4 (gt_TYPE_SSIZE_T): Work in spite of -Werror. Applied. I'm not Bruno, but yes, please apply that. Thanks. I asked, because I also had to break upstream sync with gettext, also applied: config/ChangeLog: 2006-06-15 Eric Blake [EMAIL PROTECTED] * srclist.txt (ssize_t.m4): Lose sync. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEkUw/84KuGfSFAYARAn2yAKC81LNTW4z5PiD39jtmx40ko0nBCACgnkYS 5WebLBf/ZOwlfbbf19K4uDM= =wabP -END PGP SIGNATURE- Index: config/srclist.txt === RCS file: /sources/gnulib/gnulib/config/srclist.txt,v retrieving revision 1.126 diff -u -p -r1.126 srclist.txt --- config/srclist.txt 30 May 2006 23:56:35 - 1.126 +++ config/srclist.txt 15 Jun 2006 11:59:08 - @@ -87,7 +87,7 @@ $GETTEXT/gettext-runtime/m4/wchar_t.m4 $GETTEXT/gettext-runtime/m4/wint_t.m4 m4 $GETTEXT/gettext-tools/m4/sig_atomic_t.m4 m4 $GETTEXT/gettext-tools/m4/signalblocking.m4m4 -$GETTEXT/gettext-tools/m4/ssize_t.m4 m4 +#$GETTEXT/gettext-tools/m4/ssize_t.m4 m4 # new argp not in glibc yet --13feb06.
Re: regex.c not 64-bit clean (?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Santiago Vila on 6/15/2006 2:53 AM: We are getting closer: $ cd m4 $ ./configure CFLAGS=-Wall LOG-configure $ make CFLAGS='-Wall -Werror' LOG-make make[3]: Entering directory `/home/sanvila/tmp/m4/lib' gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -Werror -c strnlen1.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -Werror -c xalloc-die.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -Werror -c exitfail.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -Werror -c mbchar.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -Werror -c regex.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -Werror -c strcasecmp.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -Werror -c xmalloc.c rm -f libm4.a ar cru libm4.a strnlen1.o xalloc-die.o exitfail.o mbchar.o regex.o strcasecmp.o xmalloc.o ranlib libm4.a make[3]: Leaving directory `/home/sanvila/tmp/m4/lib' Yeah! the gnulib portion compiled error-free! I'll go ahead and commit my patch to convert m4 1.4.x to use gnulib, now that I have proof it makes a positive difference. I'll visit the other failures on m4-patches only; no need for further gnulib traffic, once the gnulib portion is clean. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEkU0K84KuGfSFAYARAjvsAJ9k0TZUR2eE0Qs9rMjpXWe3lfeFxACgmWPX IXjRK84mCoq7cVTpmo36vlU= =scCl -END PGP SIGNATURE-
Re: regex.c not 64-bit clean (?)
Santiago Vila [EMAIL PROTECTED] writes: checking for ssize_t... no This is the crucial problem (in Output2). That test cases includes sys/types.h and decides that you don't have ssize_t, so it puts #define ssize_t int into config.h. Yet, as the other files make clear, your host does have a ssize_t typedef in sys/types.h. Can you please inspect config.log for the failing test, and find out why it mistakenly thinks your host lacks ssize_t? Thanks. You'll going to laugh at this :-) configure:8876: checking for ssize_t configure:8902: gcc -c -Wall -Werror conftest.c 5 cc1: warnings being treated as errors conftest.c: In function 'main': conftest.c:79: warning: unused variable 'x' Phooey - that means I gave bad advice. Although autoconf is getting better at working in spite of -Werror, we are not there yet. This particular case can be easily fixed, patch below; but in general it is asking for spurious failures when configuring with -Werror. Once configured, though, running make with -Werror is good policy for portability checks. What I meant to ask you to try, rather than 'configure CFLAGS=-Werror; make', was: $ ./configure CFLAGS=-Wall $ make CFLAGS='-Wall -Werror' And see if THAT combination allows gnulib regex.c to compile cleanly. Bruno, is it okay to apply this? 2006-06-14 Eric Blake [EMAIL PROTECTED] * ssize_t.m4 (gt_TYPE_SSIZE_T): Work in spite of -Werror. Index: m4/ssize_t.m4 === RCS file: /sources/gnulib/gnulib/m4/ssize_t.m4,v retrieving revision 1.9 diff -u -p -r1.9 ssize_t.m4 --- m4/ssize_t.m4 18 Jan 2005 13:07:56 - 1.9 +++ m4/ssize_t.m4 15 Jun 2006 03:15:01 - @@ -1,5 +1,5 @@ -# ssize_t.m4 serial 3 (gettext-0.13) -dnl Copyright (C) 2001-2003 Free Software Foundation, Inc. +# ssize_t.m4 serial 4 (gettext-0.13) +dnl Copyright (C) 2001-2003, 2006 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, dnl with or without modifications, as long as this notice is preserved. @@ -11,7 +11,8 @@ AC_DEFUN([gt_TYPE_SSIZE_T], [ AC_CACHE_CHECK([for ssize_t], gt_cv_ssize_t, [AC_TRY_COMPILE([#include sys/types.h], - [int x = sizeof (ssize_t *) + sizeof (ssize_t);], + [int x = sizeof (ssize_t *) + sizeof (ssize_t); +return !x], gt_cv_ssize_t=yes, gt_cv_ssize_t=no)]) if test $gt_cv_ssize_t = no; then AC_DEFINE(ssize_t, int,
Re: regex.c not 64-bit clean (?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Santiago, [adding bug-gnulib, dropping bug-m4] According to Santiago Vila on 6/12/2006 12:07 PM: I suspect it will be, since I really haven't touched regex.c that much since 1.4.4. Then try this patch which pulls the latest regex.c from gnulib: $ make clean $ patch -p0 email $ GNULIB_TOOL=../gnulib/gnulib-tool ./bootstrap $ ./configure CFLAGS='-Wall -Werror' $ make This is what happens: make all-recursive make[1]: Entering directory `/home/sanvila/tmp/m4' Making all in examples make[2]: Entering directory `/home/sanvila/tmp/m4/examples' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/sanvila/tmp/m4/examples' Making all in lib make[2]: Entering directory `/home/sanvila/tmp/m4/lib' cp ./alloca_.h alloca.h-t mv alloca.h-t alloca.h make all-am make[3]: Entering directory `/home/sanvila/tmp/m4/lib' gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -Werror -c strnlen1.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -Werror -c xalloc-die.c In file included from /usr/include/stdlib.h:433, from xalloc-die.c:26: /usr/include/sys/types.h:110: error: two or more data types in declaration specifiers make[3]: *** [xalloc-die.o] Error 1 Sounds like we have a gnulib bug on our hands, in xalloc-die. OK, remind me again what 'uname -a', 'gcc --version', and 'config.guess' report. Also, what does 'sed -ne 90,110p /usr/include/sys/types.h' show? Really nice would be narrowing in on what the preprocessor saw: $ cd lib $ gcc -E -DHAVE_CONFIG_H -I. -I.. xalloc-die.c and figure where in the output that line from stdlib was showing up. This is on a debian machine with architecture ia64. Unfortunately, I am not root, so I can't change anything in the build environment (in fact I've had to do the cvs and bootstrap parts in another machine). Meanwhile, the original question was whether the gnulib version of regex.c solved the 64-bit bugs present in the years-old version that m4 1.4.4 used. Now that you have gnulib checked out, try: $ cd gnulib $ CFLAGS='-Wall -Werror' gnulib-tool --test regex and see if that compiles cleanly. If so, I can go ahead and commit my patch to use gnulib for m4 1.4.5. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEj1nr84KuGfSFAYARAseSAJ9GmOjS9eV/MxgUSXYTajX/o3SO6QCffDA4 8VvHE257xNsctjBb0sGo4oo= =WRUD -END PGP SIGNATURE-
