<div dir="ltr">Hi all,<div><br></div><div>I have a patch up for review that changes how external tools like gcc are found [0]. Short version, more specific names on the user's PATH should be found before less specific names that are in the clang install dir.</div><div><br></div><div>This was raised in a bug report [1] and I'll use that to describe the current behaviour.</div><div><br></div><div>$ clang --target=aarch64-none-elf <...><br></div><div><br></div><div>Clang looks for a GCC to use. With one of these possible names: "aarch64-elf-none-gcc", "gcc", "<span style="color:rgb(0,0,0);white-space:pre-wrap">"x86_64-unknown-linux-gnu-gcc" (which is the default triple in this example)</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">We look for each name in the installed dir first, so if clang is in /usr/bin we likely find /usr/bin/gcc. This isn't going to work for cross compiling.</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><font color="#000000"><span style="white-space:pre-wrap">As in the bug, the user might expect clang to find an aarch64-elf-none-gcc on their PATH if there is one. So my change switches things so that we look for each name in the install dir (the "program path") and then the PATH. So in this case we would search for aarch64-none-elf-gcc in the install dir and on the PATH, before falling back to look for "gcc", and so on.</span></font></div><div><font color="#000000"><span style="white-space:pre-wrap"><br></span></font></div><div><font color="#000000"><span style="white-space:pre-wrap">That makes sense for this situation but this code is quite generic so I wanted to check if it's going to work for others. No existing tests were broken by my patch, but I think that's probably just a lack of coverage on this piece of code.</span></font></div><div><font color="#000000"><span style="white-space:pre-wrap"><br></span></font></div><div><font color="#000000"><span style="white-space:pre-wrap">A couple of things to note:</span></font></div><div><font color="#000000"><span style="white-space:pre-wrap">* -B paths are not changed by my patch, they still follow the old behaviour.</span></font></div><div><font color="#000000"><span style="white-space:pre-wrap">* You can work around this quite easily with -ccc-gcc-name or -B</span></font></div><div><font color="#000000"><span style="white-space:pre-wrap"><br></span></font></div><div><font color="#000000"><span style="white-space:pre-wrap">Looking for feedback from anyone who is involved in toolchain packaging or has been in this area recently. Is this an improvement overall and will it break existing usage?</span></font></div><div><font color="#000000"><span style="white-space:pre-wrap"><br></span></font></div><div><font color="#000000"><span style="white-space:pre-wrap">Thanks,</span></font></div><div><font color="#000000"><span style="white-space:pre-wrap">David Spickett.</span></font></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">[0] </span><a href="https://reviews.llvm.org/D79842">https://reviews.llvm.org/D79842</a></div><div>[1] <a href="https://bugs.llvm.org/show_bug.cgi?id=45693">https://bugs.llvm.org/show_bug.cgi?id=45693</a></div></div>