Re: depcomp deficiency [was: m4-1.4.7 build feedback]

[Ralf Wildenhues]

Hello Nelson, Eric,

Thanks for the bug report.

* Eric Blake wrote on Wed, Sep 27, 2006 at 04:21:27AM CEST:
> According to Nelson H. F. Beebe on 9/26/2006 8:51 AM:
> > Machinetype:            Sun W40z (4 CPUs, 2400 MHz AMD64 Opteron, 8GB RAM); 
> > FreeBSD 6.1-RELEASE #0
> > Configure environment:  CC=/usr/bin/c89 CFLAGS=-I/usr/local/include 
> > CXX=/usr/bin/g++
> > 
> > if /usr/bin/c89 -DHAVE_CONFIG_H -I. -I. -I..  -I../lib -I../lib   
> > -I/usr/local/include -MT m4.o -MD -MP -MF ".deps/m4.Tpo" -c -o m4.o m4.c; \
> >     then mv -f ".deps/m4.Tpo" ".deps/m4.Po"; else rm -f ".deps/m4.Tpo"; 
> > exit 1; fi
> > c89: illegal option -- M
> > usage: c89 [-cEgOs] [-D name[=value]] ... [-I directory] ... [-L directory] 
> > ...
> >            [-o outfile] [-U name] ... operand ...
> > 
> >        where operand is one or more of file.c, file.o, file.a
> >        or -llibrary
> > make[2]: *** [m4.o] Error 1

> What a wimpy compiler wrapper.  If they're going to wrap gcc, they might
> as well recognize options that are pure POSIX extensions rather than
> crashing on them.

Hehe, the compiler wrapper is interesting in that it depends upon the
order of the arguments whether it crashes or not.

> > It is probably not worth trying to fix this, although doing so would
> > likely enhance portability to a wider range of c89 and c99 compilers
> > on other systems.

It's certainly worth fixing this, but it will probably not affect other
systems, IMVHO.

> In short, the problem here is that the depcomp algorithm for determining
> what dependency checking to request is being fooled by the fact that your
> compiler claims to be gcc thanks to its definition of __GNUC__,

No, that is not the issue in this case.  The Automake dependency tests
are pure functionality tests (unlike, say, some of Libtool's tests).

> then fails
> to recognize -M options for dependency checking.  A fix would have to come
> from automake, which maintains depcomp, to gracefully try whether -M
> actually works before deciding that a compiler is really gcc3 compatible.

Yes.  The bug in Automake is that the _AM_DEPENDENCIES test uses a different
argument order than what is used later, during compilation:

| $ c89 -MT sub/conftest.o -MD -MP -MF sub/conftest.TPo -c -o sub/conftest.o 
sub/conftest.c
| c89: illegal option -- M
| usage: c89 [-c] [-D name[=value]] [...] [-E] [-g] [-I directory ...]
|        [-L directory ...] [-o outfile] [-O] [-s] [-U name ...] operand ...
| 
|        where operand is one or more of file.c, file.o, file.a
|        or -llibrary
| $ c89 -c -o sub/conftest.o sub/conftest.c -MT sub/conftest.o -MD -MP -MF 
sub/conftest.TPo
| sub/conftest.c:7: warning: ISO C forbids an empty source file
| $ echo $?
| 0

I'll look into a fix.  (I suspect that when it comes to argument
ordering, there are more potential problem areas lingering in the
autotools.)

The FreeBSD folks may want to know about this bug in their wrapper;
but come to think of it, I'm not even sure that it is a bug, or maybe
intended behavior.

Cheers,
Ralf