* bug#37999: clang fails to pickup/supply startfiles to ld
2019-10-30 20:48 bug#37999: clang fails to pickup/supply startfiles to ld Carl Dong
@ 2019-10-31 7:55 ` Mathieu Othacehe
2019-10-31 13:16 ` Bengt Richter
2019-10-31 14:11 ` Mathieu Othacehe
2 siblings, 0 replies; 9+ messages in thread
From: Mathieu Othacehe @ 2019-10-31 7:55 UTC (permalink / raw)
To: Carl Dong; +Cc: 37999
[-- 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"
^ permalink raw reply related [flat|nested] 9+ messages in thread* bug#37999: clang fails to pickup/supply startfiles to ld
2019-10-30 20:48 bug#37999: clang fails to pickup/supply startfiles to ld Carl Dong
2019-10-31 7:55 ` Mathieu Othacehe
@ 2019-10-31 13:16 ` Bengt Richter
2019-10-31 14:11 ` Mathieu Othacehe
2 siblings, 0 replies; 9+ messages in thread
From: Bengt Richter @ 2019-10-31 13:16 UTC (permalink / raw)
To: Carl Dong; +Cc: 37999
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
^ permalink raw reply [flat|nested] 9+ messages in thread* bug#37999: clang fails to pickup/supply startfiles to ld
2019-10-30 20:48 bug#37999: clang fails to pickup/supply startfiles to ld Carl Dong
2019-10-31 7:55 ` Mathieu Othacehe
2019-10-31 13:16 ` Bengt Richter
@ 2019-10-31 14:11 ` Mathieu Othacehe
2019-10-31 22:57 ` Marius Bakke
2 siblings, 1 reply; 9+ messages in thread
From: Mathieu Othacehe @ 2019-10-31 14:11 UTC (permalink / raw)
To: Carl Dong; +Cc: 37999
[-- 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
^ permalink raw reply related [flat|nested] 9+ messages in thread* bug#37999: clang fails to pickup/supply startfiles to ld
2019-10-31 14:11 ` Mathieu Othacehe
@ 2019-10-31 22:57 ` Marius Bakke
2019-11-04 20:31 ` Carl Dong
0 siblings, 1 reply; 9+ messages in thread
From: Marius Bakke @ 2019-10-31 22:57 UTC (permalink / raw)
To: Mathieu Othacehe, Carl Dong; +Cc: 37999
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#37999: clang fails to pickup/supply startfiles to ld
2019-10-31 22:57 ` Marius Bakke
@ 2019-11-04 20:31 ` Carl Dong
2019-11-05 7:55 ` Mathieu Othacehe
0 siblings, 1 reply; 9+ messages in thread
From: Carl Dong @ 2019-11-04 20:31 UTC (permalink / raw)
To: Marius Bakke; +Cc: 37999@debbugs.gnu.org
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.
^ permalink raw reply [flat|nested] 9+ messages in thread