[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snapshot 2 in preparation for 1.4.13
From: |
Eric Blake |
Subject: |
Re: snapshot 2 in preparation for 1.4.13 |
Date: |
Wed, 21 Jan 2009 06:14:42 -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
According to Gary V. Vaughan on 1/21/2009 1:30 AM:
Hi Gary, and thanks for the detailed reports. We may want to subdivide
replies into one email per topic, but for now, here's a bulk response:
> i686-redhat-linux9-gcc322 m4 tests pass, gnulib fails:
> test-fseeko.sh, test-ftello.sh
Known failures on older systems with broken ungetc; at this point, I'm
okay with the idea of releasing in spite of these failures, unless we can
get some more investigation into how to resolve the problem in gnulib.
> sparc-sun-solaris2.8-suncc58 m4 tests pass, gnulib fails: test-mbrtowc4.sh
> (m4-1.4.12 everything passes, but there is no test-mbrtowc4.sh)
This module is relatively new, so there are probably still lurking bugs
that you can help Bruno solve with a more detailed report about the
test-mbrtowc4 failure.
> powerpc-ibm-aix6.1.0.0-xlc101 cannot compile:
> xlc -I. -O2 -qlanglvl=extc99 -qro -qroconst -qmaxmem=-1
> -qarch=ppc -c -o strtod.o strtod.c
> "strtod.c", line 155.17: 1506-045 (S) Undeclared identifier HUGE_VAL.
> "strtod.c", line 170.17: 1506-232 (I) Divisor for modulus or
> division operator cannot be zero.
Line 155 is a use of HUGE_VAL, line 170 of NAN. Preprocessed source might
be interesting, to see if we are somehow including /usr/include/math.h
incorrectly once lib/math.h enters the picture.
>
> powerpc-ibm-aix5.3.0.0-xlc80 m4 test fails: 191.sysval
> powerpc-ibm-aix5.2.0.0-xlc80 m4 test fails: 191.sysvar
> Checking ./191.sysval
> @ ../doc/m4.texinfo:6604: Origin of test
> ./191.sysval: stdout mismatch
> *** m4-tmp.766156/m4-xout Wed Jan 21 05:58:19 2009
> --- m4-tmp.766156/m4-out Wed Jan 21 05:58:19 2009
> ***************
> *** 1,5 ****
>
> ! 2304
> --- 1,5 ----
>
> ! 127
127 often implies program not found; and this was on an attempt to run
'kill -9 $$' under system(). Can you manually use kill(1) on these
machines to cause a program to exit with SIGKILL instead of 127? I don't
know of an easy way to skip just syscmd tests in this case. Did you run
with make -k to also run the gnulib unit tests?
>
> ia64-hp-hpux11.23-acc622 m4 tests pass, gnulib fails to compile
> test-stdint.c
> cc -AC99 -I. -I../lib -I. -I. -I.. -I./.. -I../lib -I./../lib -z
> +O2 +Ofltacc +Olit=all +Oentrysched +Odataprefetch +Onolimit -c
> test-stdint.c
> "test-stdint.c", line 87: error #2018: expected a ")"
> #if INT8_MIN && INT8_MAX && INT16_MIN && INT16_MAX && INT32_MIN && INT32_MAX
> ^
> "test-stdint.c", line 87: error #2059: function call is not allowed in a
> constant expression
> #if INT8_MIN && INT8_MAX && INT16_MIN && INT16_MAX && INT32_MIN && INT32_MAX
> ^
> ...and many more similar errors
What does our replacement lib/stdint.h look like? Did config.log report
that stdint.h was broken? Maybe we just need to beef up the .m4 check.
>
> hppa2.0w-hp-hpux11.23-hpc1111 m4 tests pass, gnulib fails: test-c-stack.sh
> ./test-c-stack.sh[7]: 2972 Memory fault(coredump)
> FAIL: test-c-stack.sh
Was this with or without libsigsegv? It would be nice to characterize
what is failing here, and beef up this code.
>
> hppa2.0-hp-hpux10.20-hpc1037 m4 fails: stackovf.test
> Stack soft limit set to 300K
> Failure - m4 aborted unexpectedly
> Output from m4:
> m4: internal error detected; please report this bug to
> <address@hidden>: Segmentation fault
Now we are getting to an older machine, but probably a similar failure to
the other HPUX c-stack failures.
> alphaev5-dec-osf4.0d-cc55 fails to compile:
> cc -std -I. -ieee -O2 -nodtk -msym -readonly_strings -c -o
> gl_avltree_oset.o gl_avltree_oset.c
> cc: Warning: ///usr/include.dtk/stdlib.h, line 26: "include_next" is
> an invalid preprocessor directive, and is being ignored.
> #include_next <stdlib.h>
> -^
Hmm. What did config.log say about the compiler's ability to support
include_next? Maybe we need to further condition that logic to filter out
this compiler's bugs?
> HTH,
Indeed it helps!
- --
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
iEYEARECAAYFAkl3H8IACgkQ84KuGfSFAYCZ/QCdFbh6HlgIyfJ+jJ9gohyl24+M
r1gAoLUP+VHhA1JGsjRGEKMsY/oGNMxa
=3Xnw
-----END PGP SIGNATURE-----