Open mortenmj opened 1 month ago
It sounds like this should probably be fixed by making sure the toolchain can optionally include the files and makes sure they're laid out on disk in a place that llvm_{cov,profdata}
can find. Happy to review a PR fixing this!
@illicitonion I'm not sure we can feasibly lay out the files on disk in a way that the library would be resolved automatically, but we could set LD_LIBRARY_PATH
as part of invoking llvm_{cov,profdata}
. I suspect we'd, in Starlark, set an environment variable pointing to the location of the library, if it is provided, and then set LD_LIBRARY_PATH
in collect_coverage.rs if that environment variable is set. How do you feel about that approach?
@illicitonion friendly ping
Yeah, it may not be that we can just automatically lay things out on disk right for things to Just Work, but it feels like the solution here should be to make sure that the llvm_*
binaries are standalone executable - maybe the simplest way of making that be the case is to generate a shell script in the rust toolchain alongside the relevant binaries which sets up an LD_LIBRARY_PATH
or similar?
I would definitely model this problem as "Produce a binary that can be run without needing more configuration" rather than "Change how collect_coverage.rs
invokes things to know about the internals of the toolchain" if at all possible...
Code coverage is collected by collect_coverage.rs. This binary invokes
llvm_profdata
andllvm_cov
, which both dynamically link tolibLLVM
(e.g.libLLVM-17-rust-1.77.0-stable.so
). While this library is part of the Rust distributed archive, it is not included in the toolchain, or leading to thecollect_coverage
binary only functioning if Rust is installed locally.