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

[Mathieu Othacehe]

Hello Carl,

The attached patch fixes it for me, but this piece of code should be
rewritten so that we don't have the same failure at every clang major
version update.

WDYT?

Mathieu

>From ac0cf4e25f9acdb02bee402b45a8f31a4830fcb7 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe <address@hidden>
Date: Thu, 31 Oct 2019 08:52:39 +0100
Subject: [PATCH] gnu: clang-from-llvm: Fix linking.

* gnu/packages/llvm.scm (clang-from-llvm)[arguments]: Support clang 8 in
set-glibc-file-names phase.
---
 gnu/packages/llvm.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/packages/llvm.scm b/gnu/packages/llvm.scm
index 9a42d4fe07..46f35434a1 100644
--- a/gnu/packages/llvm.scm
+++ b/gnu/packages/llvm.scm
@@ -204,7 +204,7 @@ compiler.  In LLVM this library is called \"compiler-rt\".")
                            (compiler-rt (assoc-ref inputs "clang-runtime")))
                        (case (string->number ,(version-major
                                                (package-version 
clang-runtime)))
-                         ((or 6 7)
+                         ((or 6 7 8)
                           ;; Link to libclang_rt files from clang-runtime.
                           (substitute* "lib/Driver/ToolChain.cpp"
                             (("getDriver\\(\\)\\.ResourceDir")
-- 
2.23.0

Carl Dong writes:

> 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
> address@hidden
> "I fight for the users"