rust-lld fails with "dyld: Library not loaded: @rpath/libLLVM.dylib" on 1.30.0-nightly (02cb8f2a4 2018-08-29) #53813

parasyte · 2018-08-30T03:55:44Z

Short description: I am building for a no_std environment using cargo-xbuild, and the embedded lld as my linker of choice. The linker fails to load since it depends on a dynamic library that doesn't actually exist.

$ rustc --version
rustc 1.30.0-nightly (02cb8f2a4 2018-08-29)

$ rustc --print sysroot
/Users/parasyte/.rustup/toolchains/nightly-x86_64-apple-darwin

$ /Users/parasyte/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/bin/rust-lld --help
dyld: Library not loaded: @rpath/libLLVM.dylib
  Referenced from: /Users/parasyte/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/bin/rust-lld
  Reason: image not found
Abort trap: 6

$ otool -L /Users/parasyte/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/bin/rust-lld
/Users/parasyte/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/bin/rust-lld:
	@rpath/libLLVM.dylib (compatibility version 1.0.0, current version 7.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)

Rolling back to nightly-2018-08-27-x86_64-apple-darwin works

$ rustup override set nightly-2018-08-27-x86_64-apple-darwin
info: using existing install for 'nightly-2018-08-27-x86_64-apple-darwin'
info: override toolchain for '/Users/parasyte/projects/technek' set to 'nightly-2018-08-27-x86_64-apple-darwin'

  nightly-2018-08-27-x86_64-apple-darwin unchanged - rustc 1.30.0-nightly (721913067 2018-08-26)

$ rustc --version
rustc 1.30.0-nightly (721913067 2018-08-26)

$ rustc --print sysroot
/Users/parasyte/.rustup/toolchains/nightly-2018-08-27-x86_64-apple-darwin

$ /Users/parasyte/.rustup/toolchains/nightly-2018-08-27-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/bin/rust-lld --help
lld is a generic driver.
Invoke ld.lld (Unix), ld64.lld (macOS), lld-link (Windows), wasm-lld (WebAssembly) instead

$ otool -L /Users/parasyte/.rustup/toolchains/nightly-2018-08-27-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/bin/rust-lld
/Users/parasyte/.rustup/toolchains/nightly-2018-08-27-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/bin/rust-lld:
	/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.9.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)

The text was updated successfully, but these errors were encountered:

parasyte · 2018-08-30T04:06:56Z

Searching the source tree for rpath turns up some humorous comments...

rust/src/bootstrap/bin/rustc.rs

Lines 199 to 232 in 4f1e235

    
           // Dealing with rpath here is a little special, so let's go into some 
        
           // detail. First off, `-rpath` is a linker option on Unix platforms 
        
           // which adds to the runtime dynamic loader path when looking for 
        
           // dynamic libraries. We use this by default on Unix platforms to ensure 
        
           // that our nightlies behave the same on Windows, that is they work out 
        
           // of the box. This can be disabled, of course, but basically that's why 
        
           // we're gated on RUSTC_RPATH here. 
        
           // 
        
           // Ok, so the astute might be wondering "why isn't `-C rpath` used 
        
           // here?" and that is indeed a good question to task. This codegen 
        
           // option is the compiler's current interface to generating an rpath. 
        
           // Unfortunately it doesn't quite suffice for us. The flag currently 
        
           // takes no value as an argument, so the compiler calculates what it 
        
           // should pass to the linker as `-rpath`. This unfortunately is based on 
        
           // the **compile time** directory structure which when building with 
        
           // Cargo will be very different than the runtime directory structure. 
        
           // 
        
           // All that's a really long winded way of saying that if we use 
        
           // `-Crpath` then the executables generated have the wrong rpath of 
        
           // something like `$ORIGIN/deps` when in fact the way we distribute 
        
           // rustc requires the rpath to be `$ORIGIN/../lib`. 
        
           // 
        
           // So, all in all, to set up the correct rpath we pass the linker 
        
           // argument manually via `-C link-args=-Wl,-rpath,...`. Plus isn't it 
        
           // fun to pass a flag to a tool to pass a flag to pass a flag to a tool 
        
           // to change a flag in a binary? 
        
           if env::var("RUSTC_RPATH") == Ok("true".to_string()) { 
        
               let rpath = if target.contains("apple") { 
        
                   // Note that we need to take one extra step on macOS to also pass 
        
                   // `-Wl,-instal_name,@rpath/...` to get things to work right. To 
        
                   // do that we pass a weird flag to the compiler to get it to do 
        
                   // so. Note that this is definitely a hack, and we should likely 
        
                   // flesh out rpath support more fully in the future.

rust/src/librustc_codegen_llvm/back/linker.rs

Lines 368 to 371 in 9d69e81

    
           // Note that the `osx_rpath_install_name` option here is a hack 
        
           // purely to support rustbuild right now, we should get a more 
        
           // principled solution at some point to force the compiler to pass 
        
           // the right `-Wl,-install_name` with an `@rpath` in it.

TejasQ · 2018-08-30T14:10:33Z

I have this issue too!

GabrielMajeri · 2018-08-30T15:03:06Z

I believe this issue is caused by 3cf6f0d: "Link LLVM tools dynamically...".

It only enables dynamic linking libllvm on Linux and Mac OS, and since no Windows users complained so far I can only assume it's the probable cause.

Speaking of which, it might be a good idea to add testing the built LLVM tools / LLD to Rust's CI, to ensure issues like this are caught earlier on.

japaric · 2018-08-30T15:14:35Z

@alexcrichton @michaelwoerister this may have been caused by #53245.

Also, I don't see this issue on Linux:

$ ldd $(rustc --print sysroot)/lib/rustlib/x86_64-unknown-linux-gnu/bin/rust-lld
        linux-vdso.so.1 (0x00007ffe1cd74000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fab8c935000)
        libLLVM-7.so => /home/japaric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM-7.so (0x00007fab88ecb000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007fab88d46000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fab88d2c000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007fab88b68000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fab8c984000)
        librt.so.1 => /usr/lib/librt.so.1 (0x00007fab88b5c000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fab88b57000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fab889c8000)

$ $(rustc --print sysroot)/lib/rustlib/x86_64-unknown-linux-gnu/bin/rust-lld -flavor gnu -version
LLD 7.0.0 (compatible with GNU linkers)

$ rustc -V
rustc 1.30.0-nightly (02cb8f2a4 2018-08-29)

GabrielMajeri · 2018-08-30T15:21:56Z

@japaric I keep my toolchain updated with rustup, yet it seems I don't have libllvm.so...?

$ ldd $(rustc --print sysroot)/lib/rustlib/x86_64-unknown-linux-gnu/bin/rust-lld
        linux-vdso.so.1 (0x00007ffe30fa4000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007ff1b4c40000)
        libLLVM-7.so => not found
        libm.so.6 => /usr/lib/libm.so.6 (0x00007ff1b4abb000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007ff1b4aa1000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007ff1b48dd000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007ff1b4c9d000)

rustup update output:

info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
info: checking for self-updates

  nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.30.0-nightly (02cb8f2a4 2018-08-29)

japaric · 2018-08-30T15:46:14Z

@GabrielMajeri it seems that libLLVM.so is provided by the llvm-tools-preview component which I have installed. Try running rustup component add llvm-tools-preview and see if that fixes LLD.

@alexcrichton @michaelwoerister it sounds like libLLVM.so should always by shipped with the compiler since rust-lld depends on it.

GabrielMajeri · 2018-08-30T16:09:02Z

@japaric I installed them, but it didn't help. The LLVM tools do seem to work, and I now have the libLLVM.so library in the <rust-sysroot>/lib directory.

However, checking rust-lld's RPATH shows $ORIGIN/../lib,
i.e. it points to <rust-sysroot>/lib/rustlib/x86_64-unknown-linux-gnu/lib/.

Doing

ln -s $(rustc --print sysroot)/lib/libLLVM-7.so $(rustc --print sysroot)/lib/rustlib/x86_64-unknown-linux-gnu/lib/

does (temporarily) fix the problem.

alexcrichton · 2018-08-30T16:44:02Z

I'm working on a fix for this!

A recent change (rust-lang#53245) started to build LLVM with ThinLTO enabled and to ensure that compile times are kept down it builds LLVM dynamically by default to ensure that all the various LLVM tools aren't redoing all that optimization work. This means, however, that all LLVM tools depend on LLVM's dynamic library by default. While the LLVM tools and LLDB components were updated to include the shared library we accidentally forgot about LLD, included with the main rustc component. LLD also links dynamically to LLVM and ships a non-working binary right now because of this! This commit updates our distribution to ship the LLVM dynamic library with the compiler libraries. While not technically needed for rustc itself to operate (right now) it may be needed for LLD, and otherwise it serves as a good basis for the other LLVM tools components to work with as well. This should... Closes rust-lang#53813

alexcrichton · 2018-08-30T16:50:53Z

@japaric's diagnosis is spot on and this should be fixed in #53828

To recap, interim fixes include:

rustup component add llvm-tools-preview --toolchain nightly
Downgrading to an older nightly temporarily

TejasQ · 2018-08-30T17:03:22Z

Thanks, @alexcrichton!

rustbuild: Distribute libLLVM.so with rustc A recent change (#53245) started to build LLVM with ThinLTO enabled and to ensure that compile times are kept down it builds LLVM dynamically by default to ensure that all the various LLVM tools aren't redoing all that optimization work. This means, however, that all LLVM tools depend on LLVM's dynamic library by default. While the LLVM tools and LLDB components were updated to include the shared library we accidentally forgot about LLD, included with the main rustc component. LLD also links dynamically to LLVM and ships a non-working binary right now because of this! This commit updates our distribution to ship the LLVM dynamic library with the compiler libraries. While not technically needed for rustc itself to operate (right now) it may be needed for LLD, and otherwise it serves as a good basis for the other LLVM tools components to work with as well. This should... Closes #53813

pepyakin · 2018-08-31T16:05:43Z

rustup component add llvm-tools-preview --toolchain nightly

Doesn't work for me on macOS by the way.

thehappycoder · 2018-08-31T19:54:58Z

Edit I was wrong. It's still nightly

I get this with stable rust too (1.28.0):

192-168-1-4:wasm-game-of-life anton$ wasm-pack init
  
  [1/8] 🔧  Checking crate configuration...
  [2/8] 🎯  Adding WASM target...
\ [3/8] 🌀  Compiling to WASM...
Compilation of your program failed. stderr:

   Compiling wasm-game-of-life v0.1.0 (file:///Users/anton/projects/hacks/rust/wasm-game-of-life)
warning: function is never used: `set_panic_hook`
  --> src/utils.rs:11:9
   |
11 |         pub fn set_panic_hook() {}
   |         ^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: #[warn(dead_code)] on by default

error: linking with `rust-lld` failed: signal: 6
  |
  = note: "rust-lld" "-flavor" "wasm" "-L" "/Users/anton/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib" "/Users/anton/projects/hacks/rust/wasm-game-of-life/target/wasm32-unknown-unknown/release/deps/wasm_game_of_life.wasm_game_of_life.59gcvxac-cgu.0.rcgu.o" "/Users/anton/projects/hacks/rust/wasm-game-of-life/target/wasm32-unknown-unknown/release/deps/wasm_game_of_life.wasm_game_of_life.59gcvxac-cgu.1.rcgu.o" "/Users/anton/projects/hacks/rust/wasm-game-of-life/target/wasm32-unknown-unknown/release/deps/wasm_game_of_life.wasm_game_of_life.59gcvxac-cgu.2.rcgu.o" "-o" "/Users/anton/projects/hacks/rust/wasm-game-of-life/target/wasm32-unknown-unknown/release/deps/wasm_game_of_life.wasm" "/Users/anton/projects/hacks/rust/wasm-game-of-life/target/wasm32-unknown-unknown/release/deps/wasm_game_of_life.bxpq0uzydj2zf4e.rcgu.o" "--gc-sections" "-O3" "-L" "/Users/anton/projects/hacks/rust/wasm-game-of-life/target/wasm32-unknown-unknown/release/deps" "-L" "/Users/anton/projects/hacks/rust/wasm-game-of-life/target/release/deps" "-L" "/Users/anton/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib" "/Users/anton/projects/hacks/rust/wasm-game-of-life/target/wasm32-unknown-unknown/release/deps/libwasm_bindgen-f9f62e4f9e995bb5.rlib" "/Users/anton/projects/hacks/rust/wasm-game-of-life/target/wasm32-unknown-unknown/release/deps/libcfg_if-954cfacc8a40931a.rlib" "/Users/anton/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib/libstd-b0efc82f64d03095.rlib" "/Users/anton/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib/libpanic_abort-4f93017645c0d252.rlib" "/Users/anton/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib/libunwind-c43a3d8cf78f9d5a.rlib" "/Users/anton/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib/liblibc-68373f2b6bc18151.rlib" "/Users/anton/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib/liballoc_system-40a64b71ec5a8f18.rlib" "/Users/anton/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib/libdlmalloc-f6caffaf44cc60a0.rlib" "/Users/anton/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib/liballoc-863f2b2485046aef.rlib" "/Users/anton/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib/libcore-21433d3b7663b55b.rlib" "/Users/anton/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib/libcompiler_builtins-bf63ca2c3bc4de53.rlib" "--no-threads" "-z" "stack-size=1048576" "--stack-first" "--allow-undefined" "--no-entry" "--export-table"
  = note: dyld: Library not loaded: @rpath/libLLVM.dylib
            Referenced from: /Users/anton/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/bin/rust-lld
            Reason: image not found
          

error: aborting due to previous error

error: Could not compile `wasm-game-of-life`.

To learn more, run the command again with --verbose.

fitzgen · 2018-08-31T20:13:59Z

@thehappycoder wasm-bindgen only just had all of the features it relies on stabilize, so it is still nightly-only until those newly-stabilized features ride the release trains from nightly -> beta -> stable.

thehappycoder · 2018-08-31T21:16:11Z

@fitzgen thanks for pointing out. I just noticed that it is using nightly version. I am new to rust, so I have no idea how to rollback to previous nightly version to use as a workaround.

derekdreery · 2018-09-01T11:51:17Z

For future reference, you can use rustup to install any nightly, for instructions see the rustup github page.

pepyakin · 2018-09-01T11:58:41Z

Still getting this issue on the latest nightly:

error: linking with `rust-lld` failed: signal: 6
  |
<stripped>
note: dyld: Library not loaded: @rpath/libLLVM.dylib
            Referenced from: /Users/pepyakin/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/bin/rust-lld
            Reason: image not found

$ find ~/.rustup/toolchains/nightly-x86_64-apple-darwin | grep -i libLLVM.dylib | wc -l
       0

$ rustc +nightly -V
rustc 1.30.0-nightly (aaa170beb 2018-08-31)

$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.13.3
BuildVersion:	17D102

derekdreery · 2018-09-01T12:06:38Z

It seems to work fine for me (on arch linux)

$ rustc +nightly --version
rustc 1.30.0-nightly (aaa170beb 2018-08-31)

parasyte · 2018-09-01T18:58:38Z

I agree with @pepyakin It is still not working on macOS.

$ rustc --version
rustc 1.30.0-nightly (aaa170beb 2018-08-31)

$(rustc --print sysroot)/lib/rustlib/x86_64-apple-darwin/bin/rust-lld -flavor gnu -version
dyld: Library not loaded: @rpath/libLLVM.dylib
  Referenced from: /Users/parasyte/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/bin/rust-lld
  Reason: image not found
Abort trap: 6

$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.13.6
BuildVersion:	17G65

chinedufn · 2018-09-02T23:49:15Z

Seems like a number of people (including myself) are still having this issue, can we re-open?

michaelwoerister · 2018-09-03T09:03:41Z

Apparently #53828 did not fix this entirely on Mac OS X.

alexcrichton · 2018-09-04T19:58:22Z

I'm working on a fix for this and should be able to post it soon

steveklabnik · 2018-09-04T19:59:35Z

I'm getting this on Linux too: https://travis-ci.org/intermezzOS/kernel/jobs/424491132#L185

This commit tweaks the layout of a few components that we distribute to hopefully fix across all platforms the recent issues with LLD being unable to find the LLVM shared object. In rust-lang#53245 we switched to building LLVM as a dynamic library, which means that LLVM tools by default link to LLVM dynamically rather than statically. This in turn means that the tools, at runtime, need to find the LLVM shared library. LLVM's shared library is currently distributed as part of the rustc component. This library is located, however, at `$sysroot/lib`. The LLVM tools we ship are in two locations: * LLD is shipped at `$sysroot/lib/rustlib/$host/bin/rust-lld` * Other LLVM tools are shipped at `$sysroot/bin` Each LLVM tool has an embedded rpath directive indicating where it will search for dynamic libraries. This currently points to `../lib` and is presumably inserted by LLVM's build system. Unfortunately, though, this directive is only correct for the LLVM tools at `$sysroot/bin`, not LLD! This commit is targeted at fixing this situation by making two changes: * LLVM tools other than LLD are moved in the distribution to `$sysroot/lib/rustlib/$host/bin`. This moves them next to LLD and should position them for... * The LLVM shared object is moved to `$sysroot/lib/rustlib/$host/lib` Together this means that all tools should natively be able to find the shared object and the shared object should be installed all the time for the various tools. Overall this should... Closes rust-lang#53813

rustbuild: Tweak LLVM distribution layout This commit tweaks the layout of a few components that we distribute to hopefully fix across all platforms the recent issues with LLD being unable to find the LLVM shared object. In #53245 we switched to building LLVM as a dynamic library, which means that LLVM tools by default link to LLVM dynamically rather than statically. This in turn means that the tools, at runtime, need to find the LLVM shared library. LLVM's shared library is currently distributed as part of the rustc component. This library is located, however, at `$sysroot/lib`. The LLVM tools we ship are in two locations: * LLD is shipped at `$sysroot/lib/rustlib/$host/bin/rust-lld` * Other LLVM tools are shipped at `$sysroot/bin` Each LLVM tool has an embedded rpath directive indicating where it will search for dynamic libraries. This currently points to `../lib` and is presumably inserted by LLVM's build system. Unfortunately, though, this directive is only correct for the LLVM tools at `$sysroot/bin`, not LLD! This commit is targeted at fixing this situation by making two changes: * LLVM tools other than LLD are moved in the distribution to `$sysroot/lib/rustlib/$host/bin`. This moves them next to LLD and should position them for... * The LLVM shared object is moved to `$sysroot/lib/rustlib/$host/lib` Together this means that all tools should natively be able to find the shared object and the shared object should be installed all the time for the various tools. Overall this should... Closes #53813

TejasQ · 2018-09-05T07:42:43Z

Thanks for your super-fast help, @alexcrichton! 🚀

This commit tweaks the layout of a few components that we distribute to hopefully fix across all platforms the recent issues with LLD being unable to find the LLVM shared object. In rust-lang#53245 we switched to building LLVM as a dynamic library, which means that LLVM tools by default link to LLVM dynamically rather than statically. This in turn means that the tools, at runtime, need to find the LLVM shared library. LLVM's shared library is currently distributed as part of the rustc component. This library is located, however, at `$sysroot/lib`. The LLVM tools we ship are in two locations: * LLD is shipped at `$sysroot/lib/rustlib/$host/bin/rust-lld` * Other LLVM tools are shipped at `$sysroot/bin` Each LLVM tool has an embedded rpath directive indicating where it will search for dynamic libraries. This currently points to `../lib` and is presumably inserted by LLVM's build system. Unfortunately, though, this directive is only correct for the LLVM tools at `$sysroot/bin`, not LLD! This commit is targeted at fixing this situation by making two changes: * LLVM tools other than LLD are moved in the distribution to `$sysroot/lib/rustlib/$host/bin`. This moves them next to LLD and should position them for... * The LLVM shared object is moved to `$sysroot/lib/rustlib/$host/lib` Together this means that all tools should natively be able to find the shared object and the shared object should be installed all the time for the various tools. Overall this should... Closes rust-lang#53813

rustbuild: Tweak LLVM distribution layout This commit tweaks the layout of a few components that we distribute to hopefully fix across all platforms the recent issues with LLD being unable to find the LLVM shared object. In #53245 we switched to building LLVM as a dynamic library, which means that LLVM tools by default link to LLVM dynamically rather than statically. This in turn means that the tools, at runtime, need to find the LLVM shared library. LLVM's shared library is currently distributed as part of the rustc component. This library is located, however, at `$sysroot/lib`. The LLVM tools we ship are in two locations: * LLD is shipped at `$sysroot/lib/rustlib/$host/bin/rust-lld` * Other LLVM tools are shipped at `$sysroot/bin` Each LLVM tool has an embedded rpath directive indicating where it will search for dynamic libraries. This currently points to `../lib` and is presumably inserted by LLVM's build system. Unfortunately, though, this directive is only correct for the LLVM tools at `$sysroot/bin`, not LLD! This commit is targeted at fixing this situation by making two changes: * LLVM tools other than LLD are moved in the distribution to `$sysroot/lib/rustlib/$host/bin`. This moves them next to LLD and should position them for... * The LLVM shared object is moved to `$sysroot/lib/rustlib/$host/lib` Together this means that all tools should natively be able to find the shared object and the shared object should be installed all the time for the various tools. Overall this should... Closes #53813

dvdplm · 2018-09-06T06:36:17Z

For anyone wondering, the osx fix is not on the current nightly – rustc 1.30.0-nightly (6e0f1cc15 2018-09-05) – yet.

TejasQ · 2018-09-06T08:22:13Z

Why's this issue closed then? 🤔

jcaudle · 2018-09-06T11:32:05Z

Why's this issue closed then? 🤔

Is it because the fix will be in tomorrow's nightly build?

alexcrichton · 2018-09-06T16:30:13Z

Yes this fix missed last night's nightly but it should be in tonight's nightly!

kzvi · 2018-09-07T01:09:19Z

I'm still getting this error with rustc 1.30.0-nightly (a8c11d216 2018-09-06).

alexcrichton · 2018-09-07T02:07:41Z

Looks like there's at least one more bug to fix -- #54018

thehappycoder · 2018-09-08T09:39:54Z

Finally, I managed to compile on a mac with the latest nightly build of rust!

pepyakin mentioned this issue Aug 30, 2018

fix wasm executor compile error paritytech/substrate#631

Merged

alexcrichton mentioned this issue Aug 30, 2018

Compilation fails with an error I can't understand rustwasm/wasm-pack#275

Closed

alexcrichton mentioned this issue Aug 30, 2018

rustbuild: Distribute libLLVM.so with rustc #53828

Merged

bors closed this as completed in #53828 Aug 31, 2018

japaric mentioned this issue Aug 31, 2018

[do not merge] Fixing the Travis build rust-embedded/cortex-m-rt#101

Closed

alexcrichton mentioned this issue Aug 31, 2018

Building for wasm32-unkown-unkown fails to find libLLVM-7.so #53849

Closed

memoryruins mentioned this issue Aug 31, 2018

rust-lld: error while loading shared libraries: libLLVM-7.so on recent nightly #53869

Closed

chinedufn mentioned this issue Sep 2, 2018

error: linking with rust-lld failed: signal: 6 rustwasm/wasm-bindgen#784

Closed

robert-w-gries mentioned this issue Sep 2, 2018

Comments for "https://os.phil-opp.com/minimal-rust-kernel/" phil-opp/blog_os#403

Closed

michaelwoerister reopened this Sep 3, 2018

fitzgen mentioned this issue Sep 4, 2018

Cannot build first example rustwasm/book#87

Closed

alexcrichton mentioned this issue Sep 4, 2018

rustbuild: Tweak LLVM distribution layout #53955

Merged

alexcrichton mentioned this issue Sep 5, 2018

[experimental]: Build LLVM with ThinLTO enabled (2nd attempt) #53245

Merged

Nemo157 added a commit to Nemo157/embrio-rs that referenced this issue Sep 5, 2018

Update for new nightly (hits rust-lang/rust#53813 on macOS though)

5dc06b6

alexcrichton mentioned this issue Sep 5, 2018

Have rust-lldb look for the rust-enabled lldb #53973

Merged

bors closed this as completed in #53955 Sep 6, 2018

janhohenheim mentioned this issue Sep 7, 2018

WASM build broken on newest nightly for MacOS #54027

Closed

CRogers mentioned this issue Sep 12, 2018

Don't force usage of the nightly toolchain rustwasm/wasm-pack#289

Closed

ssundarr3 mentioned this issue Sep 19, 2020

rust-lld fails with "dyld: Library not loaded: @rpath/libLLVM.dylib" on rustc 1.48.0-nightly (bbc677480 2020-09-18) #76921

Closed

laizy mentioned this issue Sep 22, 2020

build.sh exec error ontio/ontology-wasm-cdt-rust#99

Closed

nottug mentioned this issue Feb 6, 2022

Building repo, getting "undefined symbol: setupterm" Rust-GPU/Rust-CUDA#7

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

rust-lld fails with "dyld: Library not loaded: @rpath/libLLVM.dylib" on 1.30.0-nightly (02cb8f2a4 2018-08-29) #53813

rust-lld fails with "dyld: Library not loaded: @rpath/libLLVM.dylib" on 1.30.0-nightly (02cb8f2a4 2018-08-29) #53813

parasyte commented Aug 30, 2018

parasyte commented Aug 30, 2018

TejasQ commented Aug 30, 2018

GabrielMajeri commented Aug 30, 2018 •

edited

Loading

japaric commented Aug 30, 2018 •

edited

Loading

GabrielMajeri commented Aug 30, 2018 •

edited

Loading

japaric commented Aug 30, 2018

GabrielMajeri commented Aug 30, 2018 •

edited

Loading

alexcrichton commented Aug 30, 2018

alexcrichton commented Aug 30, 2018

TejasQ commented Aug 30, 2018

pepyakin commented Aug 31, 2018

thehappycoder commented Aug 31, 2018 •

edited

Loading

fitzgen commented Aug 31, 2018

thehappycoder commented Aug 31, 2018

derekdreery commented Sep 1, 2018 •

edited

Loading

pepyakin commented Sep 1, 2018 •

edited

Loading

derekdreery commented Sep 1, 2018

parasyte commented Sep 1, 2018

chinedufn commented Sep 2, 2018

michaelwoerister commented Sep 3, 2018

alexcrichton commented Sep 4, 2018

steveklabnik commented Sep 4, 2018

TejasQ commented Sep 5, 2018

dvdplm commented Sep 6, 2018

TejasQ commented Sep 6, 2018

jcaudle commented Sep 6, 2018 •

edited

Loading

alexcrichton commented Sep 6, 2018

kzvi commented Sep 7, 2018

alexcrichton commented Sep 7, 2018

thehappycoder commented Sep 8, 2018

rust-lld fails with "dyld: Library not loaded: @rpath/libLLVM.dylib" on 1.30.0-nightly (02cb8f2a4 2018-08-29) #53813

rust-lld fails with "dyld: Library not loaded: @rpath/libLLVM.dylib" on 1.30.0-nightly (02cb8f2a4 2018-08-29) #53813

Comments

parasyte commented Aug 30, 2018

parasyte commented Aug 30, 2018

TejasQ commented Aug 30, 2018

GabrielMajeri commented Aug 30, 2018 • edited Loading

japaric commented Aug 30, 2018 • edited Loading

GabrielMajeri commented Aug 30, 2018 • edited Loading

japaric commented Aug 30, 2018

GabrielMajeri commented Aug 30, 2018 • edited Loading

alexcrichton commented Aug 30, 2018

alexcrichton commented Aug 30, 2018

TejasQ commented Aug 30, 2018

pepyakin commented Aug 31, 2018

thehappycoder commented Aug 31, 2018 • edited Loading

fitzgen commented Aug 31, 2018

thehappycoder commented Aug 31, 2018

derekdreery commented Sep 1, 2018 • edited Loading

pepyakin commented Sep 1, 2018 • edited Loading

derekdreery commented Sep 1, 2018

parasyte commented Sep 1, 2018

chinedufn commented Sep 2, 2018

michaelwoerister commented Sep 3, 2018

alexcrichton commented Sep 4, 2018

steveklabnik commented Sep 4, 2018

TejasQ commented Sep 5, 2018

dvdplm commented Sep 6, 2018

TejasQ commented Sep 6, 2018

jcaudle commented Sep 6, 2018 • edited Loading

alexcrichton commented Sep 6, 2018

kzvi commented Sep 7, 2018

alexcrichton commented Sep 7, 2018

thehappycoder commented Sep 8, 2018

GabrielMajeri commented Aug 30, 2018 •

edited

Loading

japaric commented Aug 30, 2018 •

edited

Loading

GabrielMajeri commented Aug 30, 2018 •

edited

Loading

GabrielMajeri commented Aug 30, 2018 •

edited

Loading

thehappycoder commented Aug 31, 2018 •

edited

Loading

derekdreery commented Sep 1, 2018 •

edited

Loading

pepyakin commented Sep 1, 2018 •

edited

Loading

jcaudle commented Sep 6, 2018 •

edited

Loading