rustfmt errors out on OSX

[indradhanush]

Cargo version

$ cargo -V
cargo 0.23.0 (61fa02415 2017-11-22)

Rust version

$ rustc -V
rustc 1.22.1 (05e2e1c41 2017-11-22)

Installed via

cargo +nightly install -f rustfmt-nightly

export DYLD_LIBRARY_PATH=$(rustc --print sysroot)/lib:$DYLD_LIBRARY_PATH

Error

$ rustfmt
dyld: Library not loaded: @rpath/libsyntax-6ee77dfa7d362c52.dylib
  Referenced from: /Users/dhanush/.cargo/bin/rustfmt
  Reason: image not found
Trace/BPT trap: 5

[nrc]

Could you try setting nightly to your default toolchain rather than using +nightly? If that works, you can either keep doing that or go back to the current setup but with something like rustup run nightly rustc rather than just rustc. If that doesn't work, check the value emitted by rustc --print sysroot

[SamWhited]

I'm running into this same issue on Arch. Reinstalling rustfmt fixed nothing, but reinstalling nightly and then reinstalling rustfmt worked.

EDIT: apologies, the above is not true. When testing I ran cargo fmt for some reason instead of rustfmt and I thought it worked, but it just doesn't output any error and silently fails in that case. I am still having this issue on arch.

EDIT: Actually, the above is also only partially true; it appears that cargo fmt did work, however, the second time I tried to run it it did not. I only have one version of rustfmt installed on my system, so I'm not sure why it worked exaclty once and then couldn't load libsyntax again. I'm having trouble reproducing it again now though.

EDIT: Last edit I hope… tried a few more times an the cargo fmt issue was a red herring and appears to be completely different. cargo fmt is working fine, rustfmt is failing with the error the OP reported.

[garretttaco]

cargo fmt is working fine, rustfmt is failing with the error the OP reported.

I am experiencing the same thing

The output from rustc --print sysroot is as follows

/Users/user/.rustup/toolchains/nightly-x86_64-apple-darwin

[nrc]

I'm a bit suspicious about seeing @rpath in the library path, I don't know what it means, but it looks a bit weird to me.

[SamWhited]

Mine doesn't actually mention @rpath, on Arch the error is: rustfmt: error while loading shared libraries: libsyntax-67ca56ff80aeea6f.so: cannot open shared object file: No such file or directory

I'm not sure if that matters though, still seems like the same problem.

[nrc]

Could someone please verify if the referenced library does actually exist or not? I'm not clear if this is an error because we're looking for a file which is not there or an error loading or seeing the file.

I'm curious about why this has started happening now. The only reason I can imagine is because of the version of rustfmt which is now distributed by rustup. However, rustup is designed to address these issues, and I don't see how this can be caused by the rustup change.

[SamWhited]

Where do you expect it to look? I will verify when I'm next at my desk.

EDIT: assuming this is the correct directory I have:

$ find ~/.rustup -name 'libsyntax-*.so'
/home/sam/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libsyntax-67ca56ff80aeea6f.so
/home/sam/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libsyntax-67ca56ff80aeea6f.so

I then did cargo uninstall rustfmt-nightly && cargo install rustfmt-nightly and:

$ rustc --print sysroot
/home/sam/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu
$ rustfmt
rustfmt: error while loading shared libraries: libsyntax-67ca56ff80aeea6f.so: cannot open shared object file: No such file or directory

[nrc]

@SamWhited thanks for checking! So it looks like the library is there, but the rustfmt executable can't find it when loading. Which is weird!

[SamWhited]

@nrc It appears to be looking in the wrong place according to strace: openat(AT_FDCWD, "/usr/lib/libsyntax-67ca56ff80aeea6f.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

[nrc]

interesting, thanks!

cc @alexcrichton - any idea what is going on here? Could it be something to do with the new rustup shim?

[topecongiro]

Looks like LD_LIBRARY_PATH and DYLD_LIBRARY_PATH is disabled by default in macOS (System Integrity Protection is enabled by default).

For those who cannot or do not want to use LD_LIBRARY_PATH and alike, you could add rpath to the binary when installing rustfmt via:

#!/bin/sh

mkdir -p rustfmt_build/.cargo
cd rustfmt_build
cat >.cargo/config <<EOL
[build]
rustflags = [
    "-C", "link-arg=-Xlinker",
    "-C", "link-arg=-rpath=$(rustc --print sysroot)/lib",
]
EOL
cargo install --force rustfmt-nightly

[nrc]

Indeed, SIP does prevent a program setting DYLD_LIBRARY_PATH (we've had this problem with the RLS), but it does still let you set it from the command line. I'm also not sure why it would start to be a problem now when it has not previously been a problem?

[yanickxia]

i has same problem, "Reason: image not found" , Add DYLD_LIBRARY_PATH not work..

rustc 1.24.0-nightly (dc39c3169 2017-12-17)

[topecongiro]

With rustup 0.1.8 you could install rustfmt via rustup component add rustfmt-preview.

[SamWhited]

With rustup 0.1.8 you could install rustfmt via rustup component add rustfmt-preview.

How do you use it after installing that way? I see the binary, but it doesn't appear to be putting it on my path with rustc et al.

[nrc]

Using rustup does not quite work yet (I think) - we need another rustup release.

[basbossink]

I've tried some of the suggestions above but run into the same problems on XUbuntu
Linux irimi 4.10.0-42-generic #46-Ubuntu SMP Mon Dec 4 14:38:01 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Distributor ID: Ubuntu
Description:    Ubuntu 17.04
Release:    17.04  
Codename:   zesty

~/projects/functions $ cargo -V
cargo 0.25.0-nightly (e08f31018 2017-12-24)
~/projects/functions $ rustc -V
rustc 1.24.0-nightly (cddc4a62d 2017-12-26)
~/projects/functions $ echo $LD_LIBRARY_PATH
~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib
~/projects/functions $ echo $DYLD_LIBRARY_PATH
~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib
~/projects/functions $ rustfmt
/home/bas/.cargo/bin/rustfmt: error while loading shared libraries: libsyntax-c5e24bbdfb3d58aa.so: cannot open shared object file: No such file or directory
~/projects/functions $ ls $LD_LIBRARY_PATH
libarena-c9e3dec955723747.so                  librustc_mir-2e7fd0be604d04c4.so
libfmt_macros-4bc47d6f05f81efa.so             librustc_passes-e8dcdd8aebf7c731.so
libgraphviz-f29db016833d96ec.so               librustc_platform_intrinsics-178af7c51ea9014b.so
libproc_macro-92f77a1ba5f89e22.so             librustc_plugin-429d1a098a08782a.so
librustc-b60bfec71dee4a36.so                  librustc_privacy-0eb865fc0f29b45a.so
librustc_allocator-db8c2ec298ec60e5.so        librustc_resolve-130c3ca5eb11bab8.so
librustc_back-e1aed71628604ca2.so             librustc_save_analysis-4eb653061d834f2d.so
librustc_borrowck-d6f6eb14966ed1fe.so         librustc_trans-ed03b61ec3d4fac5.so
librustc_const_eval-5c289523b17d0be7.so       librustc_trans_utils-f34528ea91d426d0.so
librustc_const_math-702b69989c008d97.so       librustc_typeck-89b7061b9860fa40.so
librustc_cratesio_shim-5944579ec963940a.so    libserialize-ecb51565a6c16608.so
librustc_data_structures-5984f08b7367a561.so  libstd-152059dc9ab225d8.so
librustc_driver-4fdbdf2acc11ea4e.so           libsyntax-c5e24bbdfb3d58aa.so
librustc_errors-e23287571adfe67a.so           libsyntax_ext-b1e6dd13c698247b.so
librustc_incremental-ec83d98e73ee2220.so      libsyntax_pos-a65a2a0131399f01.so
librustc_lint-5ff2f18c3acadf6f.so             libterm-b966231ea475f591.so
librustc_llvm-581ea60079b79359.so             libtest-7ff905b2347c5330.so
librustc_metadata-c24a25568a1b62d9.so         rustlib

Using the suggested shell script above yielded the same results. So this problem is not OSX only.

[crumblingstatue]

Rustfmt works fine if I install it through cargo install rustfmt-nightly, but gives me error while loading shared libraries: libsyntax-b49630d3cf2d806c.so: cannot open shared object file: No such file or directory if I install it through rustup component add rustfmt-preview --toolchain=nightly.

In fact, there is no libsyntax-b49630d3cf2d806c.so in ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/:

$ ls ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/ | grep syntax
libsyntax-8aaeebacc14aeeb9.so
libsyntax_ext-a73e53485f665c7c.so
libsyntax_pos-1462b087d479200c.so

Oops, I had my old rustfmt install (through cargo) still present, disregard this.

[ascclemens]

I think this is the same issue, but I can run rustfmt if I set LD_LIBRARY_PATH, but it doesn't seem to recognize the toolchain it's on.

% LD_LIBRARY_PATH=$(rustc --print sysroot)/lib rustfmt --version
0.3.4-nightly ( )
% rustc --version
rustc 1.25.0-nightly (e6072a7b3 2018-01-13)
% LD_LIBRARY_PATH=$(rustc --print sysroot)/lib rustfmt --config-path .rustfmt.toml --unstable-features src/commands/race.rs
Unstable features are only available on Nightly channel

[nrc]

If anyone is still having problems with this issue, I recommend installing rustfmt via rustup (rustup component add rustfmt-preview). Let me know if there are still issues with the rustup version and I'll re-open.