-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Nelson H. F. Beebe on 4/3/2008 3:53 PM:
| I've just built and installed m4-1.4.11 on most machines in our test
| lab of about 20 flavors of Unix covering most major CPU architectures.
Thanks for the feedback. The failures are all in gnulib portability code,
and don't appear to immediately impact m4 behavior (the gnulib
replacements are more general than what m4 uses them for). Meanwhile, can
you please rerun with 'make -k' to get the full set of failures? I
suspect checks/157.format might fail on some of the platforms (probably
all of them where strtod failed), but hopefully everything else works just
fine.
|
| Here is a summary of the failures:
|
| ------------------------------------------------------------------------
| Machinetype: DEC Alphastation 200 4/100 (1 CPU, 100 MHz Alpha
21064 EV4, 64MB RAM); GNU/Linux 2.4.19-xfs-gentoo-cd
> Configure environment: CC=/usr/bin/gcc CFLAGS="-mieee" CXX=g++
CXXFLAGS="-mieee"
|
| FAIL: test-fseeko.sh
Not much detail on the failure there. I guess we could improve
test-fseeko.c to do better line number reporting. Can you please run
test-fseeko in a debugger to see where the failure is? I'm guessing it
has to do with ungetc of random bytes, which doesn't impact m4 behavior
(m4 only ungets previously read bytes, which tends to be more reliable).
| test-ftello.c:92: assertion failed
| ./test-ftello.sh: line 3: 20362 Aborted (core dumped)
./test-ftello${EXEEXT} 1 <"$srcdir/test-ftello.sh"
| FAIL: test-ftello.sh
My guess above is especially true, since this is another instance of
broken stdio behavior after random ungetc (again, not an impact to m4
behavior). Are you able to help us port stdio fixes for your platform?
| [The same errors happen in a build with CC=gcc]
Because your system stdio library is faulty (compared to POSIX 2001), not
the compiler.
|
| ------------------------------------------------------------------------
| Machinetype: Sun W40z (4 CPUs, 2400 MHz AMD64 Opteron, 8GB
RAM); Fedora 8 (Werewolf)
|
| configure without options or environment variables
|
| FAIL: test-strtod
Previously reported. The strtod.m4 test wasn't strong enough to filter
out your non-C99 strtod. Recompile with 'gl_cv_func_strtod_works=no
./configure' and this should go away.
| The same failure occurs with a customized build:
|
| Configure environment: CC=gcc CXX=g++ LDFLAGS="-L/usr/local/lib
- -Wl,-rpath,/usr/local/lib" FC=g77 F77=g77
Again, because the problem is in libc, not the compiler.
|
| ------------------------------------------------------------------------
| Machinetype: SGI O2 R10000-SC (150 MHz); IRIX 6.5
| Configure environment: CC=c89 CXX=CC CFLAGS=-I/usr/local/include
CXXFLAGS=-I/usr/local/include LDFLAGS=-Wl,-rpath,/usr/local/libn32
|
| test-vasprintf-posix.c:1309: assertion failed
| /bin/sh[9]: 1710567 Abort(coredump)
| FAIL: test-vasprintf-posix
This is Bruno's domain.
| ------------------------------------------------------------------------
| Machinetype: SGI O2 R10000-SC (150 MHz); IRIX 6.5
|
| configure without options or environment variables
|
| test-frexpl.c:78: assertion failed
| /bin/sh[9]: 1798891 Abort(coredump)
| FAIL: test-frexpl
|
| test-isnanl.h:56: assertion failed
| /bin/sh[9]: 1583655 Abort(coredump)
| FAIL: test-isnanl-nolibm
|
| test-vasprintf-posix.c:549: assertion failed
| /bin/sh[9]: 1785979 Abort(coredump)
| FAIL: test-vasprintf-posix
More of Bruno's domain. Long doubles are portability nightmare.
| ------------------------------------------------------------------------
| Machinetype: Sun X4500 (2 CPUs, 2600 MHz AMD64 Opteron, 4GB
RAM); Solaris 10
|
| configure without options or environment variables
|
| gcc -std=gnu99 -I. -g -O2 -MT strtod.o -MD -MP -MF .deps/strtod.Tpo
- -c -o strtod.o strtod.c
| strtod.c: In function `rpl_strtod':
| strtod.c:155: error: incompatible types in assignment
| strtod.c:257: error: wrong type argument to unary minus
double num = HUGE_VAL;
return negative ? -HUGE_VAL : HUGE_VAL
Hmm - what is HUGE_VAL defined to on your platform? It should resolve to
infinity, if your hardware supports IEEE (or close to it). And even if
HUGE_VAL is a float, the implicit cast should not cause an error. It
looks like lib/math.in.h needs to work around your broken header.
| strtod.c:170: error: incompatible types in assignment
double num = NAN;
Can you determine if your platform defined NAN, or if you were using our
replacement from lib/math.h? Again, if your system defines it, what is
the definition?
| -----------------------------------------------------------------------
| Machinetype: Sun Ultra 5/400; GNU/Linux
2.4.26-sparc-r2
(Gentoo 1.4.16)
|
| configure without options or environment variables
|
| FAIL: test-fseeko.sh
| test-ftello.c:92: assertion failed
| ./test-ftello.sh: line 3: 23721 Aborted (core dumped)
./test-ftello${EXEEXT} 1 <"$srcdir/test-ftello.sh"
| FAIL: test-ftello.sh
More ungetc problems, but on Sun instead of DEC Alphastation.
Thanks again for the reports.
| - Salt Lake City, UT 84112-0090, USA URL:
http://www.math.utah.edu/~beebe/ -
Hmm - I'm only a few miles away from you!
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-----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
iEYEARECAAYFAkf1i+YACgkQ84KuGfSFAYAxNwCgxpo8rSjwoApQ9V/4/7hGXQFW
S9YAoNcTQICHsJptQmQ7pMfgs05OfF2f
=JYKo
-----END PGP SIGNATURE-----
_______________________________________________
Bug-m4 mailing list
Bug-m4@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-m4
