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

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

[Carl Dong]

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"

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

[Mathieu Othacehe]

[-- Attachment #1: Type: text/plain, Size: 185 bytes --]


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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gnu-clang-from-llvm-Fix-linking.patch --]
[-- Type: text/x-diff, Size: 1138 bytes --]

From ac0cf4e25f9acdb02bee402b45a8f31a4830fcb7 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe <m.othacehe@gmail.com>
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


[-- Attachment #3: Type: text/plain, Size: 3917 bytes --]


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

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

[Bengt Richter]

Hi Carl,

On +2019-10-30 20:48:55 +0000, Carl Dong wrote:
> 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:
>

I suppose you know that guix ld is more complex than plain vanilla gnu.
I was curious, and poked around a bit, but I don't have time to pursue it.
But here is an intereting sampler:

--8<----(spelunking guix ld)-----------cut here---------------start------------->8---
[05:48 ~/bs]$ which ld|xargs readlink -f
/gnu/store/9ysmg2739n1ms84lx6hifncgc5l2hiy9-ld-wrapper-0/bin/ld
[05:48 ~/bs]$ which ld|xargs readlink -f|xargs file
/gnu/store/9ysmg2739n1ms84lx6hifncgc5l2hiy9-ld-wrapper-0/bin/ld: a /gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash script, ASCII text e
xecutable
[05:48 ~/bs]$ which ld|xargs readlink -f|xargs wc
  289  1272 11903 /gnu/store/9ysmg2739n1ms84lx6hifncgc5l2hiy9-ld-wrapper-0/bin/ld
[05:49 ~/bs]$ which ld|xargs readlink -f|xargs cat -n|head
     1  #!/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash
     2  # -*- mode: scheme; coding: utf-8; -*-
     3
     4  # XXX: We have to go through Bash because there's no command-line switch to
     5  # augment %load-compiled-path, and because of the silly 127-byte limit for
     6  # the shebang line in Linux.
     7  # Use `load-compiled' because `load' (and `-l') doesn't otherwise load our
     8  # .go file (see <http://bugs.gnu.org/12519>).
     9  # Unset 'GUILE_LOAD_COMPILED_PATH' to make sure we do not stumble upon
    10  # incompatible .go files.  See
[05:49 ~/bs]$ which ld|xargs readlink -f|xargs cat -n|grep -i real
    66  (define %real-ld
   273    ;; Invoke the real `ld' with ARGS, augmented with `-rpath' switches.
   285                %real-ld args)
   287      (apply execl %real-ld (basename %real-ld) args)))
[05:50 ~/bs]$ which ld|xargs readlink -f|xargs cat -n|grep -im1 -A 2 real
    66  (define %real-ld
    67    ;; Name of the linker that we wrap.
    68    "/gnu/store/02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1/bin/ld")
[05:51 ~/bs]$
[05:52 ~/bs]$ readlink -f /gnu/store/02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1/bin/ld
/gnu/store/02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1/bin/ld
[05:54 ~/bs]$ file /gnu/store/02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1/bin/ld
/gnu/store/02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1/bin/ld: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /gnu/st
ore/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28//lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped
[05:54 ~/bs]$ file /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28//lib/ld-linux-x86-64.so.2
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28//lib/ld-linux-x86-64.so.2: symbolic link to ld-2.28.so
[05:56 ~/bs]$ readlink -f /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28//lib/ld-linux-x86-64.so.2
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-2.28.so
[05:57 ~/bs]$ file /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-2.28.so
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-2.28.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
--8<----(spelunking guix ld)-----------cut here---------------end--------------->8---

HTH in some way.
--
Regards,
Bengt Richter

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

[Mathieu Othacehe]

[-- Attachment #1: Type: text/plain, Size: 74 bytes --]


This patch is a bit more viable that the previous one I think.

Mathieu


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gnu-clang-from-llvm-Fix-set-glibc-file-names-phase.patch --]
[-- Type: text/x-diff, Size: 2229 bytes --]

From f126146880e3904f39728313dfc10288b51fc23a Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe <m.othacehe@gmail.com>
Date: Thu, 31 Oct 2019 15:05:54 +0100
Subject: [PATCH] gnu: clang-from-llvm: Fix set-glibc-file-names phase.

* gnu/packages/llvm.scm (clang-from-llvm)[arguments]: Turn case on major
version into a cond, so that newer versions of clang have the same behaviour as
version 6 and 7.
---
 gnu/packages/llvm.scm | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/gnu/packages/llvm.scm b/gnu/packages/llvm.scm
index 9a42d4fe07..850f05b9bf 100644
--- a/gnu/packages/llvm.scm
+++ b/gnu/packages/llvm.scm
@@ -201,10 +201,12 @@ compiler.  In LLVM this library is called \"compiler-rt\".")
                    'unpack 'set-glibc-file-names
                    (lambda* (#:key inputs #:allow-other-keys)
                      (let ((libc (assoc-ref inputs "libc"))
-                           (compiler-rt (assoc-ref inputs "clang-runtime")))
-                       (case (string->number ,(version-major
-                                               (package-version clang-runtime)))
-                         ((or 6 7)
+                           (compiler-rt (assoc-ref inputs "clang-runtime"))
+                           (version
+                            (string->number
+                             ,(version-major (package-version clang-runtime)))))
+                       (cond
+                         ((> version 3)
                           ;; Link to libclang_rt files from clang-runtime.
                           (substitute* "lib/Driver/ToolChain.cpp"
                             (("getDriver\\(\\)\\.ResourceDir")
@@ -220,7 +222,7 @@ compiler.  In LLVM this library is called \"compiler-rt\".")
                             ;; allow crt1.o & co. to be found.
                             (("@GLIBC_LIBDIR@")
                              (string-append libc "/lib"))))
-                         ((3)
+                         (else
                           (substitute* "lib/Driver/Tools.cpp"
                             ;; Patch the 'getLinuxDynamicLinker' function so that
                             ;; it uses the right dynamic linker file name.
-- 
2.23.0

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

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

Mathieu Othacehe <m.othacehe@gmail.com> writes:

> From f126146880e3904f39728313dfc10288b51fc23a Mon Sep 17 00:00:00 2001
> From: Mathieu Othacehe <m.othacehe@gmail.com>
> Date: Thu, 31 Oct 2019 15:05:54 +0100
> Subject: [PATCH] gnu: clang-from-llvm: Fix set-glibc-file-names phase.
>
> * gnu/packages/llvm.scm (clang-from-llvm)[arguments]: Turn case on major
> version into a cond, so that newer versions of clang have the same behaviour as
> version 6 and 7.

LGTM.  It will have to wait for the next 'staging' window, though.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Carl Dong]

Thank you so much Mathieu for the patch!

Marius: I believe this will only cause a rebuild for clang and not llvm, which means that it only affects ~30 packages. Perhaps this can go in master? Would love to know your thoughts.

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

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, October 31, 2019 10:57 PM, Marius Bakke <mbakke@fastmail.com> wrote:

> Mathieu Othacehe m.othacehe@gmail.com writes:
>
> > From f126146880e3904f39728313dfc10288b51fc23a Mon Sep 17 00:00:00 2001
> > From: Mathieu Othacehe m.othacehe@gmail.com
> > Date: Thu, 31 Oct 2019 15:05:54 +0100
> > Subject: [PATCH] gnu: clang-from-llvm: Fix set-glibc-file-names phase.
> >
> > -   gnu/packages/llvm.scm (clang-from-llvm)[arguments]: Turn case on major
> >     version into a cond, so that newer versions of clang have the same behaviour as
> >     version 6 and 7.
> >
>
> LGTM. It will have to wait for the next 'staging' window, though.

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

[Mathieu Othacehe]

> Marius: I believe this will only cause a rebuild for clang and not
> llvm, which means that it only affects ~30 packages. Perhaps this can
> go in master? Would love to know your thoughts.

There is also the problem that IceCat depends on Rust which depends on
Clang as stated by Mark.

Mathieu

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

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 141 bytes --]

Wait.  Rust depends on clang?  I'm pretty sure that's not the case.

The only time gnu/packages/rust.scm refers to clang is to delete it.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Mathieu Othacehe]

Hello,

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

Mathieu