Re: m4 tests failed

[Eric Blake]

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

Please keep replies on the list, so that others can pitch in.

According to Piotr Tarnowski on 9/27/2007 7:11 AM:
> Eric Blake napisaB(a):
>> Hi Piotr, and thanks for the report.  Can you please rerun with 'make -k
>> check' to ensure the rest of the testsuite is okay?
> 
> 
> Hi,
> I did 'gmake -k check 2>&1|tee ../make-k-check.out'
> output is in attachement.

> FAIL: test-closein.sh

This one may already be fixed in CVS.  At any rate, could you run 'cd
tests; sh -vx ./test-closein.sh' so we can make sure where it is failing?


> test-vasprintf-posix.c:164: assertion failed
> /bin/bash: line 4:  2124 Abort                   (core dumped) EXEEXT=''
EXEEXT='' EXEEXT='' srcdir='.' EXEEXT='' srcdir='.' EXEEXT='' srcdir='.'
${dir}$tst
> FAIL: test-vasprintf-posix

Already what we are looking at, which explains this followon failure, also
related to *printf...

> Checking ./138.format
> @ ../doc/m4.texinfo:4894: Origin of test
> ./138.format: stdout mismatch
> 4c4
> < 56790
> ---
> > 56789
> 7c7
> < success
> ---
> > 0P+0


These other two failures both have to do with regular expressions, and
since the gnulib regex replacement was used, this bothers me a bit:

> Checking ./126.regexp
> @ ../doc/m4.texinfo:4622: Origin of test
> ./126.regexp: stdout mismatch
> 1c1
> < 5
> ---
> > 0

Here, the only failing line was
 regexp(`GNUs not Unix', `\<[a-z]\w+')

> Checking ./134.patsubst
> @ ../doc/m4.texinfo:4808: Origin of test
> ./134.patsubst: stdout mismatch
> 5c5
> < GN not
> ---
> >

And here, the failure was

define(`upcase', `translit(`$*', `a-z', `A-Z')')dnl
define(`downcase', `translit(`$*', `A-Z', `a-z')')dnl
define(`capitalize1',
       `regexp(`$1', `^\(\w\)\(\w*\)',
               `upcase(`\1')`'downcase(`\2')')')dnl
define(`capitalize',
       `patsubst(`$1', `\w+', `capitalize1(`\&')')')dnl
capitalize(`GNUs not Unix')

Both of them have \w in the regex; I wonder if that is a factor?

> config.log is in attachement too. I hope this helps.

Indeed.
>   $ ./configure --prefix=/usr/local --program-prefix=g
...
> configure:2917: cc -fast -xautopar -fast -xautopar -fast -xautopar
conftest.c  >&5
> cc: Warning: -xarch=native has been explicitly specified, or implicitly
specified by a macro option, -xarch=native on this architecture implies
- -xarch=sparcvis2 which generates code that does not run on pre UltraSPARC
III processors
> configure:2920: $? = 0

I bet that warning gets annoying after a while.

> configure:4761: checking for cc option to accept ISO C99
> configure:4920: cc  -c -fast -xautopar -fast -xautopar conftest.c >&5
> cc: Warning: -xarch=native has been explicitly specified, or implicitly
specified by a macro option, -xarch=native on this architecture implies
- -xarch=sparcvis2 which generates code that does not run on pre UltraSPARC
III processors
> "/usr/include/stdbool.h", line 42: #error: "Use of <stdbool.h> is valid
only in a c99 compilation environment."
...
> configure:4952: result: unsupported

So, based on your compiler complaints, it appears that it has a C99 mode,
but that we don't know the magic to turn it on.  Can you investigate what
compiler flag is necessary to get c99 enabled on your setup?  (At least
the gnulib stdbool replacement worked).

> configure:10210: checking whether printf supports size specifiers as in C99
> configure:10319: result: yes
> configure:10324: checking whether printf supports 'long double' arguments
> configure:10401: result: yes
> configure:10406: checking whether printf supports infinite 'double'
arguments
> configure:10533: result: no
> configure:10549: checking whether printf supports infinite 'long double'
arguments
> configure:10787: result: no
> configure:10797: checking whether printf supports the 'a' and 'A' directives
> configure:10926: result: no
> configure:10931: checking whether printf supports the 'F' directive
> configure:11016: result: yes
> configure:11021: checking whether printf supports the 'n' directive
> configure:11089: result: yes
> configure:11094: checking whether printf supports POSIX/XSI format
strings with positions
> configure:11165: result: yes
> configure:11170: checking whether printf supports the grouping flag
> configure:11239: result: yes
> configure:11244: checking whether printf supports the zero flag correctly
> configure:11316: result: no

So, configure detected that printf supports long double, but not infinite
long double.  What does this program do for you?

#include <stdio.h>
int main() {
  printf("%g %d\n", (long double) 1.5, 33);
}

Maybe Bruno can chime in with more tests to try?

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

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

iD8DBQFG/FDx84KuGfSFAYARAtt5AKCl9qlq7VGo/IZ+PTBsTxcXOi+lcwCgrkQQ
x/MZ+Xj1IdxXpOFekLopMCs=
=Q0vN
-----END PGP SIGNATURE-----