Change:
Short description: I am building for a environment using , and the embedded as my linker of choice. The linker fails to load since it depends on a dynamic library that doesn't actually exist. Rolling back to works
Searching the source tree for turns up some humorous comments...
I have this issue too!
I believe this issue is caused by : "Link LLVM tools dynamically...". It only enables dynamic linking on Linux and Mac OS, and since no Windows users complained so far I can only assume it's the probable cause. <hr/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.
this may have been caused by . Also, I don't see this issue on Linux:
I keep my toolchain updated with rustup, yet it seems I don't have ...? output:
it seems that is provided by the component which I have installed. Try running and see if that fixes LLD. it sounds like should always by shipped with the compiler since rust-lld depends on it.
I installed them, but it didn't help. The LLVM tools do seem to work, and I now have the library in the directory. However, checking rust-lld's RPATH shows , i.e. it points to . Doing does (temporarily) fix the problem.
I'm working on a fix for this!
diagnosis is spot on and this should be fixed in To recap, interim fixes include: Downgrading to an older nightly temporarily
Thanks,
Doesn't work for me on macOS by the way.
Edit I was wrong. It's still nightly I get this with stable rust too (1.28.0):
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.
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.
For future reference, you can use rustup to install any nightly, for instructions see .
Still getting this issue on the latest nightly:
It seems to work fine for me (on arch linux)
I agree with It is still not working on macOS.
Seems like a number of people (including myself) are still having this issue, can we re-open?
Apparently did not fix this entirely on Mac OS X.
I'm working on a fix for this and should be able to post it soon
I'm getting this on Linux too: https://travis-
Thanks for your super-fast help,
For anyone wondering, the osx fix is not on the current nightly – – yet.
Why's this issue closed then?
Is it because the fix will be in tomorrow's nightly build?
Yes this fix missed last night's nightly but it should be in tonight's nightly!
I'm still getting this error with .
Looks like there's at least one more bug to fix --
Finally, I managed to compile on a mac with the latest nightly build of rust!

Discussion:
llvm_dylib_path.display(), e); }); <del> let dst_libdir = image.join("lib"); </del> <ins> let dst_libdir = image.join("lib/rustlib").join(&*target).join("lib"); </ins> t!(fs::create_dir_all(&dst_libdir)); builder.install(&llvm_dylib_path, &dst_libdir, 0o644);

let src_bindir = builder .llvm_out(target) .join("bin"); <del> let dst_bindir = image.join("bin"); </del> <ins> let dst_bindir = image.join("lib/rustlib") .join(&*target) .join("bin"); </ins> t!(fs::create_dir_all(&dst_bindir)); for tool in LLVM_TOOLS { let exe = src_bindir.join(exe(tool, &target));