Clang compiler cannot link programs on hard float ARM system

[George Russell]

This is clang and LLVM, as retrieved via apt-get install llvm clang, from the official RPI rasbpian derived image.

I don't believe what c or c++ file is used matters; so long as it has main() and should compile to an executable program. The same file builds with g++

This bug limits the usefulness of clang - it is possible to compile to assembly, but not to have clang control the assembler and linker as would be desired.

pi@raspberrypi ~/src $ clang -x c++ interp.c -v
Debian clang version 3.0-6 (tags/RELEASE_30/final) (based on LLVM 3.0)
Target: arm-unknown-linux-gnueabihf
Thread model: posix
clang: warning: unknown platform, assuming -mfloat-abi=soft
 "/usr/bin/clang" -cc1 -triple armv4t-unknown-linux-gnueabihf -S -disable-free -disable-llvm-verifier -main-file-name interp.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-abi apcs-gnu -target-cpu arm7tdmi -msoft-float -mfloat-abi soft -target-feature +soft-float -target-feature +soft-float-abi -target-feature -neon -target-linker-version 2.22 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/3.0 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/include/c++/4.6 -internal-isystem /usr/include/c++/4.6/arm-linux-gnueabihf -internal-isystem /usr/include/c++/4.6/backward -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.0/include -internal-externc-isystem /usr/include/arm-linux-gnueabihf -internal-externc-isystem /usr/include -fdeprecated-macro -ferror-limit 19 -fmessage-length 208 -fno-signed-char -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/interp-pNYsIa.s -x c++ interp.c
clang -cc1 version 3.0 based upon llvm 3.0 hosted on arm-unknown-linux-gnueabihf
ignoring nonexistent directory "/usr/bin/../lib/clang/3.0/include"
ignoring nonexistent directory "/usr/include/c++/4.6//arm-linux-gnueabihf/32"
ignoring nonexistent directory "/usr/bin/../lib/clang/3.0/include"
ignoring duplicate directory "/usr/include/c++/4.6"
ignoring duplicate directory "/usr/include/c++/4.6/arm-linux-gnueabihf"
ignoring duplicate directory "/usr/include/c++/4.6/backward"
ignoring duplicate directory "/usr/include/c++/4.6"
ignoring duplicate directory "/usr/include/c++/4.6/backward"
ignoring duplicate directory "/usr/include/c++/4.6"
ignoring duplicate directory "/usr/include/c++/4.6/arm-linux-gnueabihf"
ignoring duplicate directory "/usr/include/c++/4.6/backward"
ignoring duplicate directory "/usr/local/include"
ignoring duplicate directory "/usr/include/arm-linux-gnueabihf"
ignoring duplicate directory "/usr/include/arm-linux-gnueabihf"
ignoring duplicate directory "/usr/include/arm-linux-gnueabihf"
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.6
 /usr/include/c++/4.6/arm-linux-gnueabihf
 /usr/include/c++/4.6/backward
 /usr/local/include
 /usr/include/arm-linux-gnueabihf
 /usr/include
 /usr/include/clang/3.0/include/
 /usr/lib/gcc/arm-linux-gnueabihf/4.6/include/
 /usr/lib/gcc/arm-linux-gnueabihf/4.6/include-fixed/
End of search list.
 "/usr/bin/as" -o /tmp/interp-kIvDIb.o /tmp/interp-pNYsIa.s
 "/usr/bin/ld" -X --hash-style=both --build-id --eh-frame-hdr -m armelf_linux_eabi -dynamic-linker /lib/ld-linux.so.3 -o a.out crt1.o crti.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/crtbegin.o -L/usr/lib/gcc/arm-linux-gnueabihf/4.6 -L/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../.. -L/lib -L/usr/lib /tmp/interp-kIvDIb.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/arm-linux-gnueabihf/4.6/crtend.o crtn.o
/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)
pi@raspberrypi ~/src $

Suggested fix? Track upstream clang / LLVM. This looks to be a bug in Clang, possibly being addressed in clang trunk.

[George Russell (grrussel)]

Filed as clang bug http://llvm.org/bugs/show_bug.cgi?id=13506

[Anton Korobeynikov (anton-korobeynikov)]

This clang is too old. The problem was fixed recently. The fix will be included into 3.2 release.

[peter green (plugwash)]

Is a backportable fix available or is upgrading to a newer upstream our only option to fix this?

[George Russell (grrussel)]

There is at least 1 commit to clang trunk to address this area;
http://llvm.org/viewvc/llvm-project?view=rev&revision=160958

There is also a further commits in this area
http://llvm.org/viewvc/llvm-project?view=rev&revision=161038
(two more are housekeeping re the git mirror of LLVM/clang)
http://llvm.org/viewvc/llvm-project?view=rev&revision=161042
http://llvm.org/viewvc/llvm-project?view=rev&revision=161043

There could be considerable difference between 3.0 and the post 3.1 trunk, however.

[peter green (plugwash)]

Clang has been fixed so it can now feed the right file names to the linker. Regular binutils seems to have problems with it though so you have to use gold and there seem to be some other problems too.

As such while this specific issue is "fixed" I cannot reccomend clang on raspbian at this time.