rustup icon indicating copy to clipboard operation
rustup copied to clipboard

Placing llvm-tools installed via rustup onto the PATH

Open davidhewitt opened this issue 2 years ago • 3 comments

Problem you are trying to solve

I have been working with the llvm-tools-preview component (in this case llvm-profdata).

These executables seem to be installed into an atypical bin directory inside the toolchain directory:

# location of llvm-profdata
~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-profdata

# location of rustc
~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc

This means that for whatever combination of OS / target / toolchain I am running, I need to deduce the correct path to llvm-profdata myself. See for example https://github.com/pydantic/pydantic-core/blob/5c696e5ab32f323753f6c4da0000f4475225673c/.github/workflows/ci.yml#L471

Solution you'd like

It would be nice to have a supported way in rustup to run llvm-profdata for the target toolchain. Maybe rustup run could add this bin directory onto the PATH, so that e.g. rustup run stable llvm-profdata just works.

Notes

No response

davidhewitt avatar Jul 04 '23 10:07 davidhewitt

This would be very helpful.

As another example, here is our workaround:

https://github.com/tock/tock/blob/f96c4ef49b25d696f2f54622bc604b32d0201cd2/boards/Makefile.common#L207

bradjc avatar Jul 21 '23 02:07 bradjc

I don't think we would start mucking with PATH again. See https://github.com/rust-lang/rustup/pull/3178.

If rustup which and rustup run, which exist to run arbitrary commands within a toolchain cannot find these binaries-in-odd-places, I think extending them to do so (safely, with root path escapes prevented etc) would be entirely reasonable.

Another approach - and this seems best to me, would be to put these files in the bin directory in the toolchain.

rbtcollins avatar Aug 14 '23 20:08 rbtcollins

It would be very useful if we could rustup which llvm-link or perhaps rustup which --component llvm-tools llvm-link. If you agree this would be useful, do you have a preference on the two syntaxes, or pointers to where you think it should be implemented?

In our case, we want to use tools like llvm-link as part of a JIT/LTO handling IR, but it seems there is no programmatic way to obtain the paths.

jedbrown avatar Jul 30 '25 22:07 jedbrown