[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