RFC: Overriding default linker at build time

I’ve been trying to build a number of applications with link time optimization, and I am finding the existing options for picking-up gold as the linker don’t play well with some of their build systems. I can’t configure the system to use gold as the default system linker since that would affect everyone working on the machine, and that is typically more then just the people working on LLVM.

There is a gcc install directory that everyone building llvm targets with ‘-DGCC_INSTALL_PREFIX=’, and looking at the driver/tool chain code, we could add a symlink to gold in there but again there are a number of non-llvm developers using that install for other purposes. If gcc has the same behavior as clang it will also start picking ‘ld’ from that path and I’ve affected everyone on the system. (Also the person who has been nice enough to maintain these installs for us is quite hesitant to the idea of modifying anything in these install directories.)

I’ve been able to use the ‘-fuse-ld=<path_to_gold>’ option on most applications, but this still has a number of drawbacks. If I add the option to the LDFLAGS of something that builds Fortran and C/C++ then the Fortran compiler doesn’t recognize it in the Fortran link steps and the compiles fail. If I add it to the C/C++ compilers (eg: export CXX="$PREFIX/bin/clang++ -flto -fuse-ld=/usr/bin/gold") then I get warnings about an unused option in all the C/C++ compile only steps, and a lot of these build have -Werror turned on. A bigger issue is builds that are using libtools, where libtools discards the -fuse-ld option in the link steps, breaking the -flto build completely.

I’d like to be able to specify a linker to use at build time. If a cmake option is set, then rather then trying to look up the default linker, ToolChain::GetLinkerPath would just return the path that was specified in the cmake configuration. This would enable being able to build and test lto builds (or test lld) without affecting anyone else.

I would appreciate any feedback. Has anyone else hit similar issues? Is there a better way to work around these issues?

Thanks
Sean Fertile

(-llvm-dev)