Re: Compiler error of m4-1.4.13 on AIX using xlc

[Eric Blake]

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

[adding bug-gnulib]

According to Jens Rehsack on 5/1/2009 5:32 AM:
> Hi Eric,

Hi Jens,

> 
> Thomas told me, you're the best person to ask for assistance regarding the
> problem below.

Well, actually 'm4 --help' (or even './configure --help', since you didn't
get to the point of a built m4 yet) would have told you that
address@hidden was the right list, without having to also ask Thomas, but
I'm glad you found the right place.

> 
> I tried to do the update to m4-1.4.13 (using PkgSrc) on AIX and got
> following error:
> 
>>  CC  regex.o
>> "regex_internal.c", line 320.48: 1506-280 (W) Function argument assignment 
>> between types "char** restrict" and "int*" is not allowed.
>> "regex_internal.c", line 388.55: 1506-280 (W) Function argument assignment 
>> between types "char** restrict" and "int*" is not allowed.
>> "regcomp.c", line 339.63: 1506-280 (W) Function argument assignment 
>> between types "char** restrict" and "int*" is not allowed.
>> "regcomp.c", line 411.57: 1506-280 (W) Function argument assignment 
>> between types "char** restrict" and "int*" is not allowed.
>> "regcomp.c", line 415.72: 1506-280 (W) Function argument assignment 
>> between types "char** restrict" and "int*" is not allowed.

All of these warnings come from wcrtomb calls.  It looks like that got
defined as a macro, but with a definition that is triggering the compiler
warning.  Although it still compiled, I think we should figure out what
went on there to clean this up.  Hmm.  Gnulib's wchar.in.h doesn't use
restrict, so I wonder where this is coming from?  Maybe a preprocessor
dump of this file would be helpful in seeing what the compiler is
complaining about.

>>  CC  strtod.o
>> "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.
>>
>> #include_next "///usr/vac/include/math.h" <-- wrong: must use /usr/include
> 
> The problem was easy to fix for the current compilation, but I don't know
> how to fix the math.in.h - or if this would be the right file to fix etc.

Actually, the fix needs to come from gnulib.  This seems like another case
where we are guessing the wrong absolute header to use when installing a
replacement for <math.h>, but off-hand I'm not sure how best to fix it.
Maybe others on the list will have some ideas of additional things to look
for.

> 
> Would be great if you could give me a hint or maybe just fix it, if you know
> how. If I should provide more logs, simply tell me what you need.

The portion of your config.log that shows where we decided that the
absolute path to <math.h> must be ///usr/vac/include/math.h might be
interesting.  Also, any preprocessor symbols in both that file and in
/usr/include/math.h that we might need to be aware of to make
#include_next work properly even if the file is included indirectly via
another system header.

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

iEYEARECAAYFAkn67EEACgkQ84KuGfSFAYAvmwCgv1InNCVX+FS7i89ifJZ7gMum
Bq0AoMJgbKBeZxxr8Gwcmsefs8w/Jb6d
=X0go
-----END PGP SIGNATURE-----