Repository navigation
rustup run nightly cargo install generates unexecutable executables #350
Description
I have a crate (xdrgen) which uses libsyntax, and so depends on nightly.
If I try to install it with:
rustup run nightly cargo install xdrgen
it generates an executable, but it can't find the libsyntax .so file:
$ : sporall:pts/3; xdrgen
xdrgen: error while loading shared libraries: libsyntax-cb705824.so: cannot open shared object file: No such file or directory
Adding RUSTFLAGS=-C rpath doesn't help; the DT_RUNPATH is added, but the paths don't match the executable's final home.
I'm not sure if rustup should be explicitly adding an rpath, or maybe cargo should do it internally. Either way, "cargo install" should always install a working executable that doesn't need LD_LIBRARY_PATH to be set. Or perhaps it should always be static?
Activity
brson commentedon Apr 21, 2016
cargo installis only designed to work with static executables. Do you know off-hard ifcargo installworks with xrdgen using other Rust installation methods?brson commentedon Apr 21, 2016
That said I would expect
-C rpathto work, but it's known to have some weird problems and is basically considered utterly broken.jsgf commentedon Apr 22, 2016
Curiously, on another system setting
-C rpathdoes work, and theDT_RUNPATHpaths are different (varying numbers of..s). I don't see why - they're both Fedora systems (22 vs 23 though), and both using current rustup as their sole means of installing/updating rust.How can I force static linking? I'd prefer it in general (I'd also like to build
rustcall statically if possible).brson commentedon Apr 25, 2016
@jsgf Right now (and for the foreseeable future) rustc plugins require dynamic linking and rustc is always compiled with dynamic linking. It would be desirable to have static linked rustc's (for example for building against musl), but it would preclude use of plugins.
jirutka commentedon Jul 22, 2016
The same problem is with clippy (#968) and rusti. These crates are the main reason why I need nightly and hence rustup, so it’s very pity that rustup doesn’t support it. :(
brson commentedon Jul 26, 2016
I have a vague notion of how to support this scenario. And something like this will need to be solved as we expand the rust platform to include more toolchain-specific tools by default.
Just like the
rustcandcargocommands in~/.cargo/binare actually hardlinks torustupthat delegate to the actual toolchain, we could haverustupinterceptcargo installand instead install a proxy executable that runs the real executable out of a different location while configuring the dynamic linker.