unable to find crtbegin.o, lgcc, lgcc_s on my host/platform Gentoo

[llvmbot]

Bugzilla Link	11298
Resolution	FIXED
Resolved on	Nov 02, 2011 15:25
Version	trunk
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@chandlerc

Extended Description

unable to find crtbegin.o, lgcc, lgcc_s on my host/platform Gentoo
$ clang --version
clang version 3.1 (trunk)
Target: x86_64-pc-linux-gnu
Thread model: posix

[13:34:59] rthompso@raker2>~
$ uname -a
Linux raker2 2.6.39-gentoo-r3 #​6 SMP Wed Aug 31 20:32:00 EDT 2011 x86_64 Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz GenuineIntel GNU/Linux

[13:35:11] rthompso@raker2>~
$ cat /etc/lsb-release
DISTRIB_ID="Gentoo"

[13:35:14] rthompso@raker2>~
$ cat /etc/gentoo-release
Gentoo Base System release 2.0.3

[13:35:20] rthompso@raker2>~
$ clang query-gcal-updated-events.c
query-gcal-updated-events.c:24:13: warning: comparison between pointer and integer ('int' and 'void *')
if (result != NULL)
~~~~~~ ^ ~~~~
query-gcal-updated-events.c:31:13: warning: comparison between pointer and integer ('int' and 'void *')
if (result != NULL)
~~~~~~ ^ ~~~~
2 warnings generated.
/usr/bin/x86_64-pc-linux-gnu-ld: cannot find crtbegin.o: No such file or directory
/usr/bin/x86_64-pc-linux-gnu-ld: cannot find -lgcc
/usr/bin/x86_64-pc-linux-gnu-ld: cannot find -lgcc_s
clang: error: linker command failed with exit code 1 (use -v to see invocation)

$ locate crtbegin.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/crtbegin.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/32/crtbegin.o

$ locate libgcc
/lib32/libgcc_s.so.1
/lib64/libgcc_s.so.1
/usr/lib64/libgccpp.a
/usr/lib64/libgccpp.la
/usr/lib64/libgccpp.so
/usr/lib64/libgccpp.so.1
/usr/lib64/libgccpp.so.1.0.3
/usr/lib64/debug/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libgcc_s.so.1.debug
/usr/lib64/debug/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/32/libgcc_s.so.1.debug
/usr/lib64/debug/usr/lib64/libreoffice/ure/lib/libgcc3_uno.so.debug
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/libgcc.a
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/libgcc_eh.a
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/libgcc_s.so
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/libgcc_s.so.1
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/32/libgcc.a
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/32/libgcc_eh.a
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/32/libgcc_s.so
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/32/libgcc_s.so.1

[llvmbot]

$ clang -v query-gcal-updated-events.c
clang version 3.1 (trunk)
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 query-gcal-updated-events.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/3.1 -fmodule-cache-path /var/tmp/clang-module-cache -fdebug-compilation-dir /home/rthompso -ferror-limit 19 -fmessage-length 126 -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/query-gcal-updated-events-vRtz1g.o -x c query-gcal-updated-events.c
clang -cc1 version 3.1 based upon llvm 3.1svn hosted on x86_64-pc-linux-gnu
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/bin/../lib/clang/3.1/include
/usr/include
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include
End of search list.
query-gcal-updated-events.c:24:13: warning: comparison between pointer and integer ('int' and 'void *')
if (result != NULL)
~~~~~~ ^ ~~~~
query-gcal-updated-events.c:31:13: warning: comparison between pointer and integer ('int' and 'void *')
if (result != NULL)
~~~~~~ ^ ~~~~
2 warnings generated.
"/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/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o crtbegin.o -L/lib/../lib64 -L/usr/lib/../lib64 -L/lib -L/usr/lib /tmp/query-gcal-updated-events-vRtz1g.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/x86_64-pc-linux-gnu-ld: cannot find crtbegin.o: No such file or directory
/usr/bin/x86_64-pc-linux-gnu-ld: cannot find -lgcc
/usr/bin/x86_64-pc-linux-gnu-ld: cannot find -lgcc_s
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[chandlerc]

What revision did you build Clang at?

Can you add '-v' to the command you posted as failing and post that output?

[llvmbot]

Done

What revision did you build Clang at?

Can you add '-v' to the command you posted as failing and post that output?

done

[llvmbot]

What revision did you build Clang at?

Can you add '-v' to the command you posted as failing and post that output?

building from trunk

[chandlerc]

Done

My ability to read is apparently lacking... Looking into this...

[llvmbot]

Done

My ability to read is apparently lacking... Looking into this...

np -- i've a meeting starting at 2 -- but will respond to any requests ASAP

[chandlerc]

I think you're defining CXX_INCLUDE_ROOT... At least I have no other explanation for this output:
clang -cc1 version 3.1 based upon llvm 3.1svn hosted on x86_64-pc-linux-gnu
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/bin/../lib/clang/3.1/include
/usr/include
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include

Note the lack of any 'ignoring nonexistent directory' lines? There should at least be a few of those.

If this is the case, using it turns off most of the clever GCC installation auto-detection. Is there a reason you're using that? It's all a bit of a hack, and really poorly tested. If without it you have problems finding libraries or headers, we can just fix the underlying code.

[llvmbot]

If this is the case, using it turns off most of the clever GCC installation
auto-detection. Is there a reason you're using that? It's all a bit of a hack,
and really poorly tested. If without it you have problems finding libraries or
headers, we can just fix the underlying code.

I'm not intentionally defining it. I'm emerging the default 9999 ebuild. Would this be the offending param?

--with-cxx-include-root=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4

[chandlerc]

If this is the case, using it turns off most of the clever GCC installation
auto-detection. Is there a reason you're using that? It's all a bit of a hack,
and really poorly tested. If without it you have problems finding libraries or
headers, we can just fix the underlying code.

I'm not intentionally defining it. I'm emerging the default 9999 ebuild.
Would this be the offending param?

--with-cxx-include-root=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4

That sounds quite likely. You should file a bug with Gentoo (or wherever you got the 9999 ebuild) and have them stop doing that.

Instead, when a new GCC version comes out that Clang doesn't support, they should file bugs / patch the Clang source code to support them; specifically InitHeaderSearch.cpp. We've fixed Clang to automatically detect and use newer GCC installations when linking, but not the libstdc++ headers.

I'd love to see us eventually have an easy way to at configure time hard code all the relevant paths, but more than that I'd like the Clang binary by default to Just Work on most distros and even as GCC gets upgraded. Thus, I've focused most of my efforts there. I've added support to Clang for finding and using GCC 4.5.3 headers on Gentoo in r143567. Let me know if you need any additional paths added.

[llvmbot]

I'm not intentionally defining it. I'm emerging the default 9999 ebuild.
Would this be the offending param?

--with-cxx-include-root=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4

That sounds quite likely. You should file a bug with Gentoo (or wherever you
got the 9999 ebuild) and have them stop doing that.

Instead, when a new GCC version comes out that Clang doesn't support, they
should file bugs / patch the Clang source code to support them; specifically
InitHeaderSearch.cpp. We've fixed Clang to automatically detect and use newer
GCC installations when linking, but not the libstdc++ headers.

I'd love to see us eventually have an easy way to at configure time hard code
all the relevant paths, but more than that I'd like the Clang binary by default
to Just Work on most distros and even as GCC gets upgraded. Thus, I've focused
most of my efforts there. I've added support to Clang for finding and using GCC
4.5.3 headers on Gentoo in r143567. Let me know if you need any additional
paths added.

OK -- thanks for your help. i'll continue to work with it tomorrow and see if I can get the above to not be passed. I'll try to get a bug into gentoo bugzilla noting this also.