ldconfig breaks when installing as user without permissions on /etc/ld.so.cache

[edunham]

If the user running multirust does not have write permissions on /etc/ld.so.cache, multirust will fail to run ldconfig with an error (in verbose mode) like

    install: running ldconfig                                                   
    /sbin/ldconfig.real: Can't create temporary cache file /etc/ld.so.cache~: Permission denied                                                           
    install: WARNING: failed to run ldconfig. this may happen when not installing as root. run with --verbose to see the error  

I assume that all non-root users trying to install Multirust will be using a custom prefix, though not all installations with a custom prefix are missing permissions in /etc/ in the way that'll cause this error.

Changing the ldconfig command in maybe_configure_ld() in the output installation script to

if [ -n "${CFG_VERBOSE-}" ]; then
ldconfig -C $CFG_DESTDIR_PREFIX/ld.so.cache

makes it run successfully for me. I checked the ld.so and ldconfig man pages and didn't find any environment variables that can be used to override the default cache location.

Should we...

1. add a --ldconfig-cache option that'll always override the ldconfig cache location when present?
2. add a --no-root option that sets the ldconfig cache to somewhere local? (either in the CFG_DESTDIR or the current directory of the install script seem like safe bets)
3. default to setting the cache somewhere we know is writable whenever there's a custom destination directory set?

[brson]

Does putting ld.so.cache in arbitrary places really result in ld finding rustc's dynamic libraries at runtime? I would guess no.

[edunham]

What would the symptoms of failure to find the dynamic libraries at runtime be? It worked fine when I tested it with a hello world type program; is there a particular type of more serious test that should break it?

Although some versions of ldconfig claim to have an option that disables caching entirely, my ldconfig 2.9 on Ubuntu 14.04 does not appear to have any way to disable caching.

[brson]

If dynamic linking is broken then the compiler won't even run.

[brson]

Oh, actually that's not true, multirust will configure the environment correctly even if ldconfig fails. Running the compiler manually should fail with a linker error. multirust which rustc will give the path to the rustc that multirust invokes, and I expect that executing it directly will fail.

[edunham]

$ multirust which rustc
/home/edunham/.multirust/toolchains/nightly/bin/rustc
$ /home/edunham/.multirust/toolchains/nightly/bin/rustc src/main.rs 
/home/edunham/.multirust/toolchains/nightly/bin/rustc: error while loading shared libraries: librustc_driver-8cf6ce90.so: cannot open shared object file: No such file or directory

Correct, my rustc won't work when invoked directly. And yet...

$ multirust which cargo
/home/edunham/.multirust/toolchains/nightly/bin/cargo
$ cargo build
$ cargo run
     Running `target/debug/hello`
hello world

Clearly I'm missing something about the relationship between rustc and cargo in this case.

[brson]

The difference is that cargo is statically linked, so doesn't depend on any libraries, while rustc is dynamically linked.