rustup run nightly cargo install generates unexecutable executables

[jsgf]

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?

[brson]

cargo install is only designed to work with static executables. Do you know off-hard if cargo install works with xrdgen using other Rust installation methods?

[brson]

That said I would expect -C rpath to work, but it's known to have some weird problems and is basically considered utterly broken.

[jsgf]

Curiously, on another system setting -C rpath does work, and the DT_RUNPATH paths 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 rustc all statically if possible).

[brson]

@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]

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]

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 rustc and cargo commands in ~/.cargo/bin are actually hardlinks to rustup that delegate to the actual toolchain, we could have rustup intercept cargo install and instead install a proxy executable that runs the real executable out of a different location while configuring the dynamic linker.