chandlerc added a comment. In https://reviews.llvm.org/D23754#580612, @mgorny wrote:
> In https://reviews.llvm.org/D23754#580441, @chandlerc wrote: > > > In https://reviews.llvm.org/D23754#580277, @mgorny wrote: > > > > > The difference is that LLVMgold.so is not used by LLVM or clang directly > > > but by the system binutils, and so it must match the ABI of the linker. > > > If you have 32-bit libclang*, LLVM_LIBDIR_SUFFIX is 32 but ld is still a > > > 64-bit executable that needs 64-bit LLVMgold.so. > > > > > > But how does that work? The LLVM libraries linked into LLVMgold.so can't be > > 32-bit if it is loaded into a 64-bit binutils. > > > Just to be clear, the suffix I'm talking about is used only in Driver to > specify location of LLVMgold.so. The file is a part of a separate 64-bit > install of LLVM (+ clang) which obviously has all the necessary 64-bit > libraries. I'm not sure it really makes sense for the Clang driver to go hunting for an LLVMgold.so from an unrelated build of Clang and LLVM. The Clang driver is going to run a particular CC1 invocation, ask it to produce bitcode, and then hand that to a linker invocation and give it a plugin to read that bitcode. I think it is reasonable for the only plugin it looks for to be the one installed alongside its lib/clang/... and not one from some other installation in some other directory. How would it even know that this other LLVMgold.so can read the bitcode that CC1 is producing? What if they're different versions? Or support different targets? https://reviews.llvm.org/D23754 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
