Subject: bug#37999: closed (Re: bug#37999: clang fails to pickup/supply startfiles to ld)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 16 Nov 2019 14:32:02 +0000

Your bug report

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

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
37999: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=37999
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#37999: clang fails to pickup/supply startfiles to ld
From: Mathieu Othacehe <[email-masked]>
To: Carl Dong <[email-masked]>
Cc: Marius Bakke <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sat, 16 Nov 2019 15:31:00 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

Hello,

I'm closing this one as you pushed the patch.

Mathieu

Subject: clang fails to pickup/supply startfiles to ld
From: Carl Dong <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 30 Oct 2019 20:48:55 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

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
[email-masked]
"I fight for the users"