The script below installs the correct links to autoload when binutils' nm, ar are started, since there is a need to rerun this each time llvm switches to a new version, I figured this -or something similar- should be part of the ebuild. But only if "gold" flag is enabled. Then, to switch to clang, (re)setting NM, AR, RANLIB in make.conf or a package env can be avoided and links are updated each time llvm is reinstalled. Currently in use here is -I run this manually after llvm build-: ./clang.linker.additions #!/bin/bash LDVER=$(binutils-config -c) PLUGPATH=/usr/${LDVER%-*}/binutils-bin/lib/bfd-plugins mkdir -vp "$PLUGPATH" rm -vf "$PLUGPATH/"*LLVM*.so "$PLUGPATH/libLTO.so" for i in \ /usr/lib/llvm/LLVMgold.so \ /usr/lib/llvm/libLLVM-*.so \ /usr/lib/llvm/libLTO.so \ ; do ln -vs "$i" "$PLUGPATH/${i##*/}" done Reproducible: Always
Are you convinced this is really necessary? $ clang -O4 -flto --verbose a.c |& grep plugin "/usr/bin/x86_64-pc-linux-gnu-ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../../lib64/crt1.o /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../../lib64/crti.o /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/4.8.1/crtbegin.o -L/usr/bin/../lib/gcc/x86_64-pc-linux-gnu/4.8.1 -L/usr/bin/../lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/bin/../lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../../x86_64-pc-linux-gnu/lib -L/usr/bin/../lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../.. -L/lib -L/usr/lib **-plugin /usr/bin/../lib64/llvm/LLVMgold.so** -plugin-opt=mcpu=x86-64 /tmp/a-722bda.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/4.8.1/crtend.o /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../../lib64/crtn.o As highlighted above, clang passes a proper plugin path to the linker. Do you need this for some older version or other use case?
It's not just clang's LTO which needs this. But tools like nm need it to be able to read LLVM bitcode object files.
(In reply to Michał Górny from comment #1) > As highlighted above, clang passes a proper plugin path to the linker. Do > you need this for some older version or other use case? This also won't work in any place where the linker is not called by clang.
Ok. I'm wondering if we should rebuild the plugin for every binutils version, or just recreate the symlinks. There's probably no clear ABI indication in binutils for that ;/. Then, there's stupid eselect-binutils that affects the actual binutils version used. Maybe we should instead have an eselect module for enabling/disabling plugins.
+ 19 Dec 2013; Michał Górny <mgorny@gentoo.org> llvm-9999.ebuild: + Symlink the LLVM gold plugin to bfd-plugins directory to enable LLVM object + support in various binutils tools, bug #462554. If you are using the live version, please test.
*llvm-3.3-r2 (28 Dec 2013) 28 Dec 2013; Michał Górny <mgorny@gentoo.org> +files/llvm-3.3-r2-gentoo-install.patch, +llvm-3.3-r2.ebuild: Backport all the fixes and install design changes from -9999 to -3.3. Fixes bugs #425844 (install CMake modules), #462554 (install bfd-plugins symlink), #489586 (multilib portage compat.), #488216, #492554 (RPATH issues).