-----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 bug...@gnu.org 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 e...@byu.net -----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-----
