clang failed to link binaries when -flto option is used.

Bug #1254970 reported by Deng Yao on 2013-11-26
This bug affects 7 people
Affects Status Importance Assigned to Milestone
llvm-toolchain-3.9 (Ubuntu)
llvm-toolchain-snapshot (Ubuntu)

Bug Description

clang-3.3/3.4 cannot link a simple binary if -flto option is used (in order to enable link-time-optimization), probably due to incorrect packaging of which can be found in /usr/lib/llvm-<version>/lib/, however the gold linker only searchs /usr/lib for

The following command clearly shows the problem:
user@ubuntu:/tmp$ echo 'int main() {}' | clang -xc - -flto -v
Ubuntu clang version 3.4-1ubuntu1 (trunk) (based on LLVM 3.4)
Target: x86_64-pc-linux-gnu
Thread model: posix
 "/usr/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -emit-llvm-bc -disable-free -disable-llvm-verifier -main-file-name - -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version -v -resource-dir /usr/bin/../lib/clang/3.4 -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.4/include -internal-isystem /usr/include/clang/3.4/include/ -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /usr/include -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 105 -mstackrealign -fobjc-runtime=gcc -fobjc-default-synthesize-properties -fdiagnostics-show-option -fcolor-diagnostics -backend-option -vectorize-loops -o /tmp/--5RQxuk.o -x c -
clang -cc1 version 3.4 based upon LLVM 3.4 default target x86_64-pc-linux-gnu
ignoring nonexistent directory "/usr/bin/../lib/clang/3.4/include"
ignoring duplicate directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
End of search list.
 "/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ -o a.out /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.8 -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../.. -L/lib -L/usr/lib -plugin /usr/bin/../lib/ -plugin-opt=mcpu=x86-64 /tmp/--5RQxuk.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.8/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o
/usr/bin/ld: /usr/bin/../lib/ error loading plugin: /usr/bin/../lib/ cannot open shared object file: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Ubuntu release 13.10

BTW, there are other issues related to link-time-optimization on ubuntu, probably upstream bugs.

Deng Yao (pad-e) on 2013-11-26
description: updated
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in llvm-toolchain-snapshot (Ubuntu):
status: New → Confirmed

Having the same problem. Is there a temporary workaround for this that makes lto work?

Ivan Kozik (ludios) wrote :

I ran into this and my workaround was:

ln -sf /usr/lib/llvm-3.4/lib/ /usr/lib/
echo /usr/lib/llvm-3.4/lib >> /etc/

I also had to add -B/usr/lib/gold-ld to my clang options to get it to use /usr/bin/ instead of /usr/bin/ld.bfd

(-B takes a directory containing ld, not a path to a linker!)

mjau (mjau-deactivatedaccount) wrote :

This still happens with clang 3.7 in Ubuntu 15.10.

Roger Binns (ubuntu-rogerbinns) wrote :

And clang 3.8 in Ubuntu 16.04.

Sebastian Ramacher (s-ramacher) wrote :

Also affects clang 3.9 in yakkety.

Sylvestre Ledru (sylvestre) wrote :

Just install llvm-3.9-dev

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers