[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ralf Wildenhues
Subject: Re: depcomp deficiency [was: m4-1.4.7 build feedback]
Date: Wed, 27 Sep 2006 10:37:17 +0200
User-agent: Mutt/1.5.13 (2006-09-08)

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 
| 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.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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]