[PATCH] D23754: cmake: Add CLANG_GOLD_LIBDIR_SUFFIX to specify loc of LLVMgold.so

Chandler Carruth via cfe-commits cfe-commits at lists.llvm.org
Thu Oct 27 01:03:19 PDT 2016


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





More information about the cfe-commits mailing list