Code change:
} } <del> // Maybe add libLLVM.so to the lib-dir. It will only have been built if // LLVM tools are linked dynamically. // // We add this to both the libdir of the rustc binary itself (for it to load at // runtime) and also to the target directory so it can find it at link-time. // // Note: This function does no yet support Windows but we also don't support //       linking LLVM tools dynamically on Windows yet. pub fn maybe_install_llvm_dylib(builder: &Builder<'_>, target: Interned<String>, sysroot: &Path) { </del> <ins> /// Maybe add libLLVM.so to the given destination lib-dir. It will only have /// been built if LLVM tools are linked dynamically. /// /// Note: This function does not yet support Windows, but we also don't support ///       linking LLVM tools dynamically on Windows yet. fn maybe_install_llvm(builder: &Builder<'_>, target: Interned<String>, dst_libdir: &Path) { </ins> let src_libdir = builder.llvm_out(target).join("lib"); <del> let dst_libdir1 = sysroot.join("lib/rustlib").join(&*target).join("lib"); let dst_libdir2 = sysroot.join(builder.sysroot_libdir_relative(Compiler { stage: 1, host: target })); t!(fs::create_dir_all(&dst_libdir1)); t!(fs::create_dir_all(&dst_libdir2)); </del> if target.contains("apple-darwin") { let llvm_dylib_path = src_libdir.join("libLLVM.dylib"); if llvm_dylib_path.exists() { <del> builder.install(&llvm_dylib_path, &dst_libdir1, 0o644); builder.install(&llvm_dylib_path, &dst_libdir2, 0o644); </del> <ins> builder.install(&llvm_dylib_path, dst_libdir, 0o644); </ins> } return; }

Related discussion:
text: Since , has been distributed in the component in two locations: (presumably as a runtime dependency of ) (not sure, maybe for linking custom drivers?) likely belongs in the component, if the duplication can't be avoided <hr/The difference can be seen in these consecutive nightlies' components: has just the second maybe it's used via relative by ? separate codegen backends are gone, maybe we should just try removing it? first nightly to include has both copies All 3 of those files are identical (even across nightlies, yay for deterministic builds): One fascinating aspect is that the size only increases from to , despite alone being uncompressed, so compression is really helping. Even the only goes from to . (I'm using archive sizes from the and directory listings in , FWIW) <hr/This part of the build system seems relevant, but I'm not sure which of the two this creates: cc
cc -- you've touched code related to this a bunch recently I think, so maybe would have some time to investigate fixing this. I suspect we want to only ship one LLVM per tarball, at least, though ideally we would only have just the one LLVM library total as well.
Half-way through writing up this issue I realized the connection. I'd suggest we try to get rid of the copy and see what breaks, it's possible it's been dead weight for a while now. And only if we have to keep both for some odd reason, we'd move it to .
The purposely orders the tarred files so that similar filenames are adjacent in the compression stream, especially in hope of helping with such duplicate files. I think we may still want the copy for the odd cross-compiled tool using , but that definitely belongs in .
Is that... even possible? Is a per-target component in the same way is?
Yes it is -- try -- but I don't know if anyone really needs that...
Actually, can you try something like cross-compiling a copy of to , after deleting the per-target ? I suspect that it would actually run just fine on a host, because 's s should only really contain the information and maybe some object code that is missing (which we could get rid of if we kept MIR for everything but idk how feasible that is). That is, the result of linking against should still use at runtime, so in is unnecessary. But maybe I'm missing something.