[distcc] -MD and -o behaviour (again)

Martin Pool mbp at sourcefrog.net
Tue Jan 14 00:07:00 GMT 2003


On 13 Jan 2003, Thomas Walker <Thomas.Walker at morganstanley.com> wrote:

> Yes, I have noticed that -MF seems to fix my problem with gcc3.2 but I am,
> unofrtunately, trying to get this working in an environment that is unlikely
> to see 2.96 disappear anytime in the near future.

Thomas, the problem is that the behaviour of -MD has changed from gcc
2.96 to 3.0 to 3.2.

There is in general *no way* to write a Makefile that will work
correctly for all versions.  For some specific cases, such as the
simplest one of both source and output being in the working directory,
it will be fine.  But in general the dependencies may end up in
different places.  I suppose your makefiles have been tweaked to work
with both versions, but it is a bit hard to everything in distcc.

Perhaps it could do a better job, but a general solution seems to be
impossible because of the gcc change.

You probably already read this

  http://distcc.samba.org/manual/html/distcc.html#toc2.11

    With gcc 2.95, -MD always writes dependencies into the preprocessor's
    working directory. distcc should work fine.

    With gcc 3.2, -MD writes the output into either the source directory
    or output directory, depending on the presence of the -o
    option. However, gcc 3.2 also has a -MF option that can be used to
    explicitly set the dependency output file, and this works well with
    distcc.

There are some other discussions in the list archive.

Here's the specific section from the gcc manual:

    If -MD is used in conjunction with -E, any -o switch is understood
    to specify the dependency output file (but see -MF), but if used
    without -E, each -o is understood to specify a target object file.

For example: 

  http://gcc.gnu.org/ml/gcc-bugs/2002-02/msg00388.html
  http://gcc.gnu.org/ml/gcc-bugs/2002-02/msg00399.html

Putting dependencies possibly in the wrong place is less bad than
failing to compile altogether, which is why distcc has the current
behaviour.

However, this seems to be not how it behaves on "gcc-3.2 (GCC) 3.2.2
20021212 (Debian prerelease)", which has the obvious behaviour of
using -o to set the preprocessor file, and writing dependencies to the
.d form of that name.

> At the moment, the only solution I've found is the afore mentioned
> two passes method (one w/ distcc for the compile, one without for
> the dependency generation).

There are some partial solutions:

 - write your Makefile for one version of gcc or the other; use -MF
   for 3.2 

 - detect the gcc version in ./configure, and output an appropriate
   Makefile 

 - always invoke the compiler from the source directory and put the
   dependencies in there

 - generate dependencies by a separate "make depend" operation

> Would you be ammenable to a patch that would allow disabling of -o
> stripping via command line switch or environment variable to support
> this kind of behaviour?

The patch should be pretty trivial.  In fact, distcc used to have this
behaviour, but it caused problems with some versions of gcc.  You can
try 0.14 if you want to see if it helps.

> Are there any other side-effects of this that I'm not seeing that
> you can think of?

Yes: it won't work with versions of gcc 3.2 that intepret "-E -MD -o"
as documented.

I can't understand what the gcc maintainers were thinking when they
decided to change the meaning of such a fundamental option as -o. :-(

-- 
Martin 



More information about the distcc mailing list