[cfe-dev] [RFC] Changing tool search path priority

[David Spickett via cfe-dev]

> ...but I don't think we should ever be looking for
> ${DEFAULT_TRIPLE}-gcc. That doesn't make sense to me at all.

IIt was added in https://reviews.llvm.org/D13340. Quoting a comment there:
""LLVMDefaultTargetTriple is the value specified with the CMake
variable -DLLVM_DEFAULT_TARGET_TRIPLE= during configuration time. For
example, using --target=mips64el-mti-linux will search for files prefixed
with either mips64el-mti-linux-{as,ld} and mips-mti-linux-{as,ld} in our
toolchain where we specify -DLLVM_DEFAULT_TARGET_TRIPLE=mips-mti-linux."

I guess that allows you to only package one copy of tools that can handle
both targets.

On Thu, 14 May 2020 at 14:34, Joerg Sonnenberger via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Thu, May 14, 2020 at 09:38:43AM +0100, David Spickett via cfe-dev wrote:
> > 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.
>
> I don't mind inverting the flow here.
>
> > This was raised in a bug report [1] and I'll use that to describe the
> > current behaviour.
> >
> > $ clang --target=aarch64-none-elf <...>
> >
> > Clang looks for a GCC to use. With one of these possible names:
> > "aarch64-elf-none-gcc", "gcc", ""x86_64-unknown-linux-gnu-gcc" (which is
> > the default triple in this example)
>
> ...but I don't think we should ever be looking for
> ${DEFAULT_TRIPLE}-gcc. That doesn't make sense to me at all.
>
> > 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.
>
> It works with as/ld in most places, but I can understand the desire to
> having them in PATH.
>
> Joerg
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200514/796c46b8/attachment.html>