bug#37999: clang fails to pickup/supply startfiles to ld

[Carl Dong <contact@carldong.me>]

Hi all,

Our clang toolchain seems to be quite broken at this time. In particular, it
fails to call `ld` in the right way such that the startfiles are picked up:

--8<---------------cut here---------------start------------->8---
$ guix environment --pure --container --ad-hoc clang@6 binutils -- clang++ -v -Xlinker --verbose
...
"/gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/bin/ld"
	--eh-frame-hdr
	-m elf_x86_64
	-dynamic-linker /lib64/ld-linux-x86-64.so.2
	-o a.out
	crt1.o
	crti.o
	/gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/crtbegin.o
	-L/gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0
	-L/gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/../../..
	-L/gnu/store/zki2b9r9lkdxnb23sqc8xs99xs9s5x03-clang-6.0.1/bin/../lib
	--verbose
	-L/gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/lib
	-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
	/gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/crtend.o
	crtn.o
...
attempt to open crt1.o failed
/gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/bin/ld: cannot find crt1.o: No such file or directory
attempt to open crti.o failed
/gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/bin/ld: cannot find crti.o: No such file or directory
...
attempt to open /gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/libm.so failed
attempt to open /gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/libm.a failed
attempt to open /gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/../../../libm.so failed
attempt to open /gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/../../../libm.a failed
attempt to open /gnu/store/zki2b9r9lkdxnb23sqc8xs99xs9s5x03-clang-6.0.1/bin/../lib/libm.so failed
attempt to open /gnu/store/zki2b9r9lkdxnb23sqc8xs99xs9s5x03-clang-6.0.1/bin/../lib/libm.a failed
attempt to open /gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/lib/libm.so failed
attempt to open /gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/lib/libm.a failed
attempt to open /gnu/store/mx2bgrpxkbdjsmhlxp9a30hbzcilk4cn-binutils-2.32/x86_64-unknown-linux-gnu/lib64/libm.so failed
attempt to open /gnu/store/mx2bgrpxkbdjsmhlxp9a30hbzcilk4cn-binutils-2.32/x86_64-unknown-linux-gnu/lib64/libm.a failed
attempt to open /no-ld-lib-path/libm.so failed
attempt to open /no-ld-lib-path/libm.a failed
attempt to open /gnu/store/mx2bgrpxkbdjsmhlxp9a30hbzcilk4cn-binutils-2.32/x86_64-unknown-linux-gnu/lib/libm.so failed
attempt to open /gnu/store/mx2bgrpxkbdjsmhlxp9a30hbzcilk4cn-binutils-2.32/x86_64-unknown-linux-gnu/lib/libm.a failed
/gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/bin/ld: cannot find -lm
...
--8<---------------cut here---------------end--------------->8---

I believe this is because we have crt1.o, crti.o, and limb.so in the output of
our glibc package, which clang seems unaware of.

I don't know exactly how to fix this, but I did some digging in the clang
codebase (cfe-6.0.1 to be exact), and found that the crt1.o, crti.o arguments
are added in lib/Driver/ToolChains/Gnu.cpp.

These arguments are constructed using something like
Args.MakeArgString(ToolChain.GetFilePath("crti.o")), which really calls
Driver::GetFilePath in lib/Driver/Driver.cpp under the hood. Meaning that we
just need to make Driver::GetFilePath aware of our glibc path and return the
correct full path to crt1.o and crti.o.

If anyone can help out here it would be much appreciated.

Cheers,
Carl Dong
contact@carldong.me
"I fight for the users"