Code change:
panic!("dist: Error calling canonicalize path `{}`: {}", llvm_dylib_path.display(), e); }); <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> } } <ins> /// Maybe add libLLVM.so to the target lib-dir for linking. pub fn maybe_install_llvm_target(builder: &Builder<'_>, target: Interned<String>, sysroot: &Path) { let dst_libdir = sysroot.join("lib/rustlib").join(&*target).join("lib"); maybe_install_llvm(builder, target, &dst_libdir); } /// Maybe add libLLVM.so to the runtime lib-dir for rustc itself. pub fn maybe_install_llvm_runtime(builder: &Builder<'_>, target: Interned<String>, sysroot: &Path) { let dst_libdir = sysroot.join(builder.sysroot_libdir_relative(Compiler { stage: 1, host: target })); maybe_install_llvm(builder, target, &dst_libdir); } </ins> #[derive(Clone, Debug, Eq, Hash, PartialEq)] pub struct LlvmTools { pub target: Interned<String>,

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.