Currently, using clang with LTO (link time optimization) does not work straight out of the box. A user wishing to leverage clang's LTO (which is good!), the following needs to be done: 1. The default linker needs to be switched from ld.bfd to ld.gold. 2. The 'ar' program needs to be made to load some LLVM plugins to work properly with the object files produced by clang (or you have linking errors trying to use LTO). See http://en.gentoo-wiki.com/wiki/Llvm#Gold_Plugin.2C_LTO This bug is about the second part. The plugins are already compiled and installed by the LLVM ebuild, but are not loaded by 'ar'. It can be solved by having the llvm ebuild install symlinks to plugins such that 'ar' will pick them up and autoload them. Reproducible: Always Steps to Reproduce: 1. Install clang and llvm with LTO support. 2. Switch to the gold linker: binutils-config --linker ld.gold 3. Try to build some CMake project, using (assuming C only project): CC=clang CFLAGS="-O2 -flto" LDFLAGS="-flto" (or anything that uses clang with LTO and makes temporary archives with 'ar'). 4. Linking fails with undefined references.
Created attachment 315777 [details, diff] ebuild patch This patch to the ebuild adds code that creates the required symlinks. It does that in a simpler way than the instructions on the wiki say. In particular, instead of creating: - symlink /usr/${CHOST}/binutils-bin/lib -> /usr/${CHOST}/lib - symlink /usr/${CHOST}/lib/bfd-plugins -> /usr/$(get_libdir)/bfd-plugins - directory /usr/$(get_libdir)/bfd-plugins - symlinks in /usr/$(get_libdir)/bfd-plugins/ to plugins in /usr/$(get_libdir)/llbm/ it just creates: - directory /usr/${CHOST}/binutils-bin/lib/bfd-plugins - symlinks in /usr/${CHOST}/binutils-bin/lib/bfd-plugins/ to plugins in /usr/$(get_libdir)/llvm/ I've tested that this does in fact work, assuming that the instructions from the wiki have not been performed or have been undone.
Also, to make LTO work you need to build llvm with 'gold' use flag (and not anything else). It would probably be a good idea to make this more obvious somehow.
That seems like a lot of symlinks to me, and I'm pretty certain I was able to get it running easier (by modifying the env). Toolchain, what do you think?
Sorry, I think I mis-read you the first time. So let's update this... (In reply to comment #1) > it just creates: > > - directory /usr/${CHOST}/binutils-bin/lib/bfd-plugins > - symlinks in /usr/${CHOST}/binutils-bin/lib/bfd-plugins/ to plugins in > /usr/$(get_libdir)/llvm/ > > I've tested that this does in fact work, assuming that the instructions from > the wiki have not been performed or have been undone. I would be fine with that but I'd like toolchain to confirm it's the right thing to do.
This should be fixed in -3.3-r1 and -9999.
(In reply to Michał Górny from comment #4) i'm not terribly familiar with llvm internals, but this seems like the simplest hack if it works ...
Well, nowadays clang should just put proper '--plugin' flags on the linker command-line.
