* Bruno Haible wrote on Sun, Apr 13, 2008 at 05:17:43PM CEST: > Ralf Wildenhues wrote: > > > c.m4 _AC_PROG_CC_C89 already checks for -Ae, so I don't understand > > why it's not used automatically (AC_PROG_CC calls that macro). > > In the particular case of HP-UX: > > - On a system where the expensive HP C compiler is not installed, the > autoconf test certainly tried "cc -Ae" and this failed, so -Ae was > not added to CC or the CFLAGS.
OK, IIUC then we don't need to care about this case at all, right? > - On a system where the expensive HP C compiler is installed: > If it's a HP-UX 10 system, "cc" is only K&R C, so _AC_PROG_CC_C89 will > add -Ae; good. OK. > If it's a HP-UX 11 system, "cc" understands ANSI C, so _AC_PROG_CC_C89 > does nothing: [...] > But -Ae is generally needed on HP-UX, so that system functions get declared > in the header files. AC_USE_SYSTEM_EXTENSIONS cares about it in the case of > GNU systems and Solaris systems, but not for HP-UX. This sounds like there's a bug in either _AC_PROG_CC_C89 or AC_USE_SYSTEM_EXTENSIONS, or both. This isn't a part of Autoconf code I know very well, so I'd appreciate if somebody else could take a look. > I can agree to dropping the recommendation to try CC="cc -Ae" if > > 1) AC_USE_SYSTEM_EXTENSIONS is modified to add -Ae on HP-UX with cc, if > it is not already present in $CC. Is there an "or" or an "and" connecting (1) and (2)? > 2) The "checking whether the C compiler works..." test is made sharper, > to reject compilers which support only K&R C and not ANSI C. Today, > even GCC and Emacs use ANSI C features. The guy in [1] (presumably > on a HP-UX 10 system, where "cc" was only K&R C and "cc -Ae" did not > work) should have received a message about his C compiler not working, > instead of bugging the Amanda developers who then bugged the gnulib > developers. Judging from the manual, I'd expect AC_PROG_CC_STDC to achieve this (so if it doesn't, it should be fixed). Cheers, Ralf
