Expect disruptions to multirust-rs self-updates


Hi there.

This morning I landed a big change to how multirust-rs does self-updates. The transition from the old system to the new has been pretty rough, and I’d recommend on holding off on running multirust self upgrade for a day or two while I work out the bugs.

If you do try to upgrade and it doesn’t go well, it should be relatively easy to recover by deleting all of the following directories and doing a fresh install. Please do let me know what went wrong though.

  • ~/.multirust
  • ~/.cargo
  • c:\Users\$USERNAME\AppData\Local\.multirust
  • c:\Users\$USERNAME\.cargo
  • c:\Users\$USERNAME\.multirust


Just tried to update, and I get

 $ multirust self update
downloading file from: 'https://github.com/Diggsey/multirust-rs-binaries/raw/master/x86_64-unknown-linux-gnu/multirust-rs.sha256'
downloading file from: 'https://github.com/Diggsey/multirust-rs-binaries/raw/master/x86_64-unknown-linux-gnu/multirust-rs'
~/.multirust/tmp/multirust-m9jgx9ru30rzd4cm_file: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
error: command failed: 'update' (Status: exit code: 127)

Trying to find libssl gives me:

$ locate libssl

So no libssl.1.0.0. This is on a standard install of CentOS 7. I can create a Github issue if you prefer.



Wow! Thanks for the report. This is not at all one of the failures I was anticipating. Nothing about how multirust-rs uses openssl has intentionnaly changed.

@alexcrichton does this ssl error mean anything to you? Perhaps I need to specify that openssl is statically linked somewhere? I see that openssl-sys supports an OPENSSL_STATIC environment variable, but how to I set it?

Please do file this on github too.


Hm that looks like the multirust binaries are linked dynamically to OpenSSL and the target system has a different version than Travis where it was built.

I think that, like Cargo, the binary distributions of multirust will want to link statically to OpenSSL. There’s a few methods of doing that:

  • Cargo uses links overrides
  • The openssl-sys crate has the OPENSSL_STATIC variable but it means you need to have statically compiled libraries somewhere (notably compiled with -fPIC which many /usr/lib ones aren’t typically)

The multirust Travis instance is already running in a docker container, and that same container has OpenSSL compiled (for Cargo). Basically, if you apply the same configuration that Cargo does, it should work.


Previous version seems to link openssl statically:

$ ldd $(which multirust)
    linux-vdso.so.1 =>  (0x00007ffc89931000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007fd2ca3cc000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd2ca1b0000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fd2c9f9a000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fd2c9bd9000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fd2ca5d0000)
    libm.so.6 => /lib64/libm.so.6 (0x00007fd2c98d7000)
    librt.so.1 => /lib64/librt.so.1 (0x00007fd2c96cf000)


Huh, multirust-rs’ travis file indicates its setting OPENSSL_STATIC: https://github.com/rust-lang-nursery/multirust-rs/blob/master/.travis.yml#L55