rustfmt can't load some dynamic libraries on macOS

[khaledkbadr]

Using rustfmt-nightly v0.1.3 and rust nightly 1.19.0-nightly (258ae6dd9 2017-06-15)
whenever I try to run rustfmt I get this error

dyld: Library not loaded: @rpath/libsyntax-714ca9b0aa3bf580.dylib
  Referenced from: /Users/Khaled/.cargo/bin/rustfmt
  Reason: image not found
Abort trap: 6

Although that cargo fmt seems to work

[nrc]

Are you using the nightly toolchain when running (e.g., by setting the rustup default toolchain to nightly or by running cargo + nightly run ...?

[khaledkbadr]

Yes, I'm setting rustup default to nightly

[nrxus]

This error also occurs on my Ubuntu machine.

$ rustfmt --help
rustfmt: error while loading shared libraries: libsyntax-4d04fe9c309dd506.so: cannot open shared object file: No such file or directory

Strangely enough, it only happens when I run rustfmt, but it works fine when I run cargo fmt:

$ cargo fmt --help

usage: cargo fmt [options]

Options:
    -h, --help          show this message
    -q, --quiet         no output printed to stdout
    -v, --verbose       use verbose output
    -p, --package <package>
                        specify package to format (only usable in workspaces)
        --all           format all packages (only usable in workspaces)

This utility formats all bin and lib files of the current crate using rustfmt. Arguments after `--` are passed to rustfmt.

This is an issue for me because rust-mode in Emacs uses the rustfmt executable to format the code. This bug means I cannot easily format my code within my editor and instead have to rely on calling for cargo fmt manually.

For context I use rustup with nightly as default:

$ rustc --version
rustc 1.20.0-nightly (445077963 2017-06-20)

Explicitely saying nightly with rustup works:

$ rustup run nightly rustfmt --help


usage: rustfmt [options] <file>...

Options:
    -h, --help          show this message
    -V, --version       show version information
    -v, --verbose       print verbose output
        --write-mode [replace|overwrite|display|diff|coverage|checkstyle]
                        mode to write in (not usable when piping from stdin)
        --skip-children 
                        don't reformat child modules
        --config-help   show details of rustfmt configuration options
        --dump-default-config PATH
                        Dumps the default configuration to a file and exits.
        --dump-minimal-config PATH
                        Dumps configuration options that were checked during
                        formatting to a file.
        --config-path [Path for the configuration file]
                        Recursively searches the given path for the
                        rustfmt.toml config file. If not found reverts to the
                        input file path
        --file-lines JSON
                        Format specified line ranges. See README for more
                        detail on the JSON format.

Exit Codes:
    0 = No errors
    1 = Encountered operational errors e.g. an IO error
    2 = Failed to reformat code because of parsing errors
    3 = Code is valid, but it is impossible to format it properly
    4 = Formatted code differs from existing code (write-mode diff only)

But that is less than desireable since I am already running with nightly as default, and I installed rustfmt-nightly using this nightly version of rust.

[topecongiro]

In Linux environment, export LD_LIBRARY_PATH=$(rustc --print sysroot)/lib:$LD_LIBRARY_PATH should work.

[nrxus]

Given this issue, the similar/duplicated windows issue #1736, and my issue on Linux it seems like the documention should address it somehow that we need to link that library manually

[kieraneglin]

For Atom users who are getting this issue when using atom-beautify, see here.

The solution for now is to checkout the rustfmt syntex branch and compile from source.

[ohbargain]

I did what @topecongiro suggested with DYLD_LIBRARY_PATH and it works on macOS

[Lakier15]

I also did what @topecongiro suggested. Works on Linux Mint

[jimmycuadra]

I'm having this problem too. I can't successfully run rustfmt at all. I've tried uninstalling and reinstalling nightly Rust and rustfmt-nightly, to no avail. Here is the behavior I'm seeing:

$ rustup show
Default host: x86_64-apple-darwin

installed toolchains
--------------------

stable-x86_64-apple-darwin
nightly-x86_64-apple-darwin (default)

installed targets for active toolchain
--------------------------------------

wasm32-unknown-emscripten
x86_64-apple-darwin

active toolchain
----------------

nightly-x86_64-apple-darwin (directory override for '/redacted')
rustc 1.20.0-nightly (c9bb93576 2017-06-24)
$ cargo install rustfmt-nightly
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading rustfmt-nightly v0.1.7
  Installing rustfmt-nightly v0.1.7
 Downloading term v0.4.6
 Downloading toml v0.4.2
   Compiling log v0.3.8
   Compiling regex-syntax v0.4.1
   Compiling diff v0.1.10
   Compiling utf8-ranges v1.0.0
   Compiling unicode-segmentation v1.2.0
   Compiling serde v1.0.9
   Compiling num-traits v0.1.39
   Compiling dtoa v0.4.1
   Compiling unicode-xid v0.0.4
   Compiling quote v0.3.15
   Compiling void v1.0.2
   Compiling libc v0.2.24
   Compiling term v0.4.6
   Compiling lazy_static v0.2.8
   Compiling getopts v0.2.14
   Compiling rustfmt-nightly v0.1.7
   Compiling itoa v0.3.1
   Compiling synom v0.11.3
   Compiling strings v0.1.0
   Compiling unreachable v1.0.0
   Compiling memchr v1.0.1
   Compiling thread_local v0.3.4
   Compiling syn v0.11.11
   Compiling aho-corasick v0.6.3
   Compiling serde_json v1.0.2
   Compiling toml v0.4.2
   Compiling regex v0.2.2
   Compiling serde_derive_internals v0.15.1
   Compiling serde_derive v1.0.9
   Compiling env_logger v0.4.3
    Finished release [optimized] target(s) in 105.85 secs
  Installing /Users/redacted/.cargo/bin/rustfmt
  Installing /Users/redacted/.cargo/bin/cargo-fmt
$ rustfmt --write-mode overwrite expand.rs
dyld: Library not loaded: @rpath/libsyntax-dbe71c0fd2acf87f.dylib
  Referenced from: /Users/redacted/.cargo/bin/rustfmt
  Reason: image not found
Abort trap: 6

It hangs forever if I run it via rustup run:

$ rustup run nightly rustfmt --write-mode overwrite expand.rs

It also hangs forever if I do:

$ export DYLD_LIBRARY_PATH=$(rustc --print sysroot)/lib
$ rustfmt --write-mode overwrite expand.rs

I've also tried it using the default write mode (currently "replace") and the behavior is the same.

Here's an excerpt of the syscalls the hung process is making (via dtruss):

open("/redacted/expand.rs\0", 0x1000000, 0x1B6)      = 3 0
dtrace: error on enabled probe ID 2134 (ID 154: syscall::read:return): invalid kernel access in action #12 at DIF offset 92
mmap(0x0, 0x200000, 0x3, 0x1002, 0xFFFFFFFF, 0x0)        = 0x103200000 0
madvise(0x102871000, 0x21000, 0x5)       = 0 0
madvise(0x10350D000, 0x81000, 0x5)       = 0 0
dtrace: error on enabled probe ID 2134 (ID 154: syscall::read:return): invalid kernel access in action #12 at DIF offset 92
close_nocancel(0x3)      = 0 0
madvise(0x102948000, 0x11000, 0x5)       = 0 0
madvise(0x1031AC000, 0x41000, 0x5)       = 0 0
madvise(0x10360C000, 0x182000, 0x5)      = 0 0
madvise(0x10320C000, 0x101000, 0x5)      = 0 0

I removed some occurrences of the "error on enabled probe ID 2134" message, which occurs a few hundred times in a row each time it's shown above.

It looks like the hanging process may be unrelated to the dynamic dyld error, because cargo fmt works on an empty lib.rs, but hangs if I replace the contents with the expand.rs file I was trying to format.

[alilleybrinker]

Just chiming in to say that @topecongiro's suggestion worked for me, and that it may be worthwhile updating the README with an installation note for macOS users.

[anderejd]

Sorry for the negative tone in this post but I want to add my perspective as a Rust user who at the moment have no interest in being a contributor to the language or the surrounding tools. The new nightly requirement for rustfmt has been pissing me off (yes I know, there are reasons) and now this. Could rustfmt instead be shipped as a prebuilt binary with the normal rustup installer?

I only want to be a normal rustfmt user, not a contributor.

[nrc]

Could rustfmt instead be shipped as a prebuilt binary with the normal rustup installer?

This is the plan, it will take a while though. Hopefully should be there in the next few months.

You can also continue to use the old Rustfmt (i.e., not the nightly version) which continues to work on stable Rust (but isn't getting updated).

[nox]

I don't quite understand why ef63830 closed this issue. This is just a workaround, not a proper fix. Why is it even needed to define DYLD_LIBRARY_PATH if the only toolchain I installed is nightly and it is the default one?

[focusaurus]

Just a note I was getting these errors on macos and I seem to have solved it with brew uninstall rust. I had from hombrew: rust and rustup-initand via rustup I had nightly installed. Something about that combination breaks but uninstalling the homebrew rust seems to have made cargo fmt work again running under rustup nightly toolchain.