Ralf Wildenhues wrote:
> the bit of qualm I have going this route is that we may
> end up with dozens of recommendations, that all apply to some
> more or less large subset of packages that use Autoconf. For
> the rest it's just bloat.
I don't see the risk of that: 12 years ago, indeed, one needed particular
recommendations for nearly every vendor. Since most of it is now in
AC_PROG_CC, and many weird systems disappeared, the list of recommendations
is short now.
> 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.
- 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.
If it's a HP-UX 11 system, "cc" understands ANSI C, so _AC_PROG_CC_C89
does nothing:
$ ./configure
checking build system type... hppa2.0w-hp-hpux11.00
checking host system type... hppa2.0w-hp-hpux11.00
checking target system type... hppa2.0w-hp-hpux11.00
checking for a BSD-compatible install... config/install-sh -c
checking whether build environment is sane... yes
...
checking for gcc... no
checking for cc... cc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... no
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of cc... hp
...
checking how to run the C preprocessor... cc -E
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.
In fact the package that the latest reporter [1] wanted to build is Amanda,
and it has a macro AMANDA_SYSHACKS which, for HP-UX, does
AMANDA_ADD_CFLAGS([-Ae])
So, apparently, this package too needs the -Ae flag. Additionally, the
configure.ac authors of this package fell into a pitfall: They added the
-Ae only in the middle of the configuration. The configuration results done
before may have been different if -Ae was used from the beginning. So, you see,
this package has trouble despite using AC_PROG_CC and AC_USE_SYSTEM_EXTENSIONS.
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.
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.
Bruno
[1] http://lists.gnu.org/archive/html/bug-gnulib/2008-04/msg00065.html
