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 cont...@carldong.me "I fight for the users"