[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: Gecko/20081209 Thunderbird/ Mnenhy/

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
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


reply via email to

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