chandlerc added a comment. In https://reviews.llvm.org/D23754#580631, @mgorny wrote:
> 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). I think all of these options are just way too much magic to support a very strange use case (IMO). Mixing and matching a 32-bit Clang build with a 64-bit LLVMgold build and expecting magic flags like '-flto' to Just Work seems like too much. It isn't like this prevents users from directly specifying things. The syntax isn't even that crazy. And that way they'll know what they're getting. > 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. Sure. Or we could tell users to directly do this and keep the '-flto' behavior maximally simple and predictable. https://reviews.llvm.org/D23754 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
