Hello Bruno, Ian,
thanks for the report.
* Bruno Haible wrote on Sat, Oct 03, 2009 at 02:42:08PM CEST:
> Here is a situation where automake 1.9.6 errs out because of a missing
> invocation of AM_PROG_CC_C_O in a configure.ac, but automake >= 1.10 don't
> err out any more and instead produces a Makefile.in that fails when the
> C compiler does not support -c and -o in the same command line.
>
> How to reproduce:
[...]
> make[4]: Entering directory `/tmp/testdir2/gllib'
> source='localcharset.c' object='localcharset.o' libtool=no \
> DEPDIR=.deps depmode=none /bin/sh ../build-aux/depcomp \
> /tmp/testdir2/build-aux/compile /tmp/oldcc -DHAVE_CONFIG_H -I. -I..
> -g -O2 -c -o localcharset.o localcharset.c
> mv: `localcharset.o' and `localcharset.o' are the same file
> ...
> make[4]: Entering directory `/tmp/testdir2/gltests'
> source='test-alloca-opt.c' object='test-alloca-opt.o' libtool=no \
> DEPDIR=.deps depmode=none /bin/sh ./../build-aux/depcomp \
> /tmp/oldcc -DHAVE_CONFIG_H -I. -I. -I. -I.. -I./.. -I../gllib
> -I./../gllib -g -O2 -c -o test-alloca-opt.o test-alloca-opt.c
> oldcc: -o and -c incompatible
> make[4]: *** [test-alloca-opt.o] Error 1
Well, the rules produced by automake assume that -c -o works when it
detects the gcc3 dependency tracking mechanism. IIRC this had been
deemed fairly safe, and reduces Makefile.in size somewhat.
If we have reports from compile wrappers that use GCC under the hood but
do not grok -c -o, then this might need to be revisited; for free
software wrappers, I'd first suggest to try to fix the wrappers, or at
least make an effort to do so.
> Both generated directories testdir1 and testdir2 have the same gnulib-tool
> generated files.
>
> There is a configure.ac for Makefile.am and gllib/Makefile.am. The latter
> contains the automake option 'subdir-objects'. configure.ac contains an
> AM_PROG_CC_C_O call, so all is fine. If that call is commented out, automake
> errs out:
> 1) in testdir1, automake 1.9.6:
> gllib/Makefile.am: C objects in subdir but `AM_PROG_CC_C_O' not in
> `configure.ac'
> 2) in testdir2, automake 1.10:
> gllib/Makefile.am:33: compiling `uniwidth/width.c' in subdir requires
> `AM_PROG_CC_C_O' in `configure.ac'
>
> There is a gltests/configure.ac for gltests/Makefile.am. The latter also
> contains the automake option 'subdir-objects'. But here gltests/configure.ac
> does not invoke AM_PROG_CC_C_O. Why does automake 1.9.6 err out in this
> situation, but automake 1.10 does not do it any more?
I think after many complaints against Automake, the error from 1.9.6
about missing AM_PROG_CC_C_O has been turned into a portability warning
in 1.10. -Wportability should be on by default in 1.10 and newer unless
you use the 'foreign' option. You should thus see it as soon as you add
-Wportability to AUTOMAKE_OPTIONS in gltests/Makefile.am.
I think it is very unfortunate that it is not sufficient to override the
warning setting on the command line. We should change that. So far I
haven't been brave enough to delve into this code very deep. (Needs
quite some research to ensure we don't break existing setups.)
The fact that the warning is output for gllib/Makefile.am is due to that
one not using 'foreign' strictness, thus -Wportability is not turned
off.
The strictness-implying-warnings semantics are described in the
`Invoking Automake' node:
`-W CATEGORY'
`--warnings=CATEGORY'
Output warnings falling in CATEGORY. CATEGORY can be one of:
[...]
The categories output by default are `syntax' and `unsupported'.
Additionally, `gnu' and `portability' are enabled in `--gnu' and
`--gnits' strictness. On the other hand, the `silent-rules'
options (*note Options::) turns off portability warnings about
recursive variable expansions.
It would probably be good to also document this in the `Strictness'
node (I don't like it all that much that 'foreign' implies no
portability warnings).
> This issue was brought up by Ian Beckwith on bug-gnulib.
Thanks,
Ralf
