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 protected]
"I fight for the users"
