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