Clang 2.9 fails to link the executable. For example: fads@extensa /tmp $ cat main.c #include <stdio.h> int main (){ printf("Hello, bugzilla!\n"); return 0; } fads@extensa /tmp $ clang main.c -o main -v clang version 2.9 (tags/RELEASE_29/final) Target: x86_64-pc-linux-gnu Thread model: posix "/usr/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name main.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21.1 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 170 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-dkk4Zj.o -x c main.c clang -cc1 version 2.9 based upon llvm 2.9 hosted on x86_64-pc-linux-gnu ignoring nonexistent directory "/usr/local/include" #include "..." search starts here: #include <...> search starts here: /usr/bin/../lib/clang/2.9/include /usr/include /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/include End of search list. "/usr/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o main /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o crtbegin.o -L -L/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/../../.. /tmp/cc-dkk4Zj.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed crtend.o /usr/lib/../lib64/crtn.o /usr/bin/ld: cannot find crtbegin.o: No such file or directory /usr/bin/ld: cannot find -lgcc /usr/bin/ld: cannot find -lgcc_s clang: error: linker command failed with exit code 1 (use -v to see invocation) Reproducible: Always The same bug on debians bugzilla http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627131
The same bug on official llvm bugzilla http://llvm.org/bugs/show_bug.cgi?id=9798
Created attachment 282355 [details, diff] patch from Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Clang works as expected after applying this patch, and modifying clang-2.9.ebuild: src_prepare() { mv "${WORKDIR}"/clang-${PV} "${S}"/tools/clang || die "clang source directory not found" + # Fix bug #377949, troubles with GCC 4.6 + epatch "${FILESDIR}"/${PN}-2.9-gcc-4.6.patch
While you're at it you can also at "4.5.3" to this list. Man, this is broken …
Created attachment 282867 [details, diff] Updates the GCC version list for all GCC releases since Clang 2.9 was tagged as of August 8, 2011 Here is a patch that covers GCC 4.4.6, GCC 4.5.3, GCC 4.6.0, GCC 4.6.1 and GCC 4.6.2. I can verify that this fixes Clang linker issues with GCC 4.4.6. I have no reason to think that it won't fix equivalent issues with GCC 4.5.3, GCC 4.6.0, GCC 4.6.1 and GCC 4.6.2.
Other people can/should test this, but I think this patch is ready for inclusion into portage. It isn't a big change and anyone with GCC 4.5.3 could verify that this patch fixes the problem. I don't have commit privileges, so I can't commit it myself. It only takes 3 commands to apply this patch to an affected system: ebuild $(equery which sys-devel/clang-2.9) unpack wget -O - "http://bugs.gentoo.org/attachment.cgi?id=282867" | patch -d/var/tmp/portage/sys-devel/clang-2.9/work -p1 ebuild $(equery which sys-devel/clang-2.9) merge
Created attachment 283263 [details, diff] modifed patch to fix clang's search path I had the same crtbegin.o error in clang and I have gcc version 4.5.3. After applying the patch, clang now works correctly. The patch didn't seem to match the clang directory structure I saw however, so I modified it to match; the modifed patch is attached.
Thanks guys, this is now fixed in 2.9-r1. Let's hope upstream will fix this properly at some point.
GCC 4.5.4 is unmasked on x64, maybe we should add it to the list. I had to change the patch manually.
