mgorny added a comment. In https://reviews.llvm.org/D23754#580620, @chandlerc wrote:
> 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? Well, this is the builder/distributor's responsibility. If they override this specific suffix, they need to ensure that the value is correct. That said, I don't mind using the generic runtimes directory approach, that is having LLVMgold.so relative to lib/clang. However, in this case it would probably be reasonable to adjust the install path in LLVM as well (the move of runtimes path to LLVM was requested separately). Another option is to just pass `--plugin=LLVMgold.so` and rely on the linker search instead of providing a full path. However, I guess that might break some uncommon installations. https://reviews.llvm.org/D23754 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
