First, a warning: If you have built parts of LLVM in the past day
you should consider doing a make clean. The problem is that the
.d files were being built with rules which will not actually get used.
This means any .o files that happened to get rebuilt will likely have
broken dependencies.
The problem is that for some object file foo.o, there typically end
being two rules. The first rule looks something like
--
Debug/Foo.o: foo.cpp Debug/.dir:
... build the file ...
--
and is used to actually build the source. The second rule comes from
the .d file and looks like:
--
Debug/foo.o: ... all sorts of header files ...
--
and the dependencies for the second rule will just get added to the
first.
It was news to me to discover that this merging of the second rule with
the first depends on the targets being identical. In particular, if the
second
rule is:
--
Debug//foo.o: ... all sorts of header files ...
--
then those dependencies are lost.
It turns out that this can be a big problem if your LLVM tree is under
a directory which is symlinked. If for whatever reason the .d files get
generated using a hard path to the file, then depending on what path
you build LLVM from the dependencies may be lost. Since the
generation of the actual .d files is somewhat unpredictable (i.e. whenever
someone changes the file) this can lead to very sporadic build failures
or miscompiles.
Does anyone have a good solution to this problem? One possible
solution which seems to work for me is to force PROJ_OBJ_ROOT to
be a hard path using realpath() via 'readlink -f'. This is fairly
straightforward
to do, but I am not sure of its portability, or if there are any unintended
consequences.
- Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20081003/206f84a1/attachment.html>
