all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#37999: clang fails to pickup/supply startfiles to ld
@ 2019-10-30 20:48 Carl Dong
  2019-10-31  7:55 ` Mathieu Othacehe
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Carl Dong @ 2019-10-30 20:48 UTC (permalink / raw)
  To: 37999

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	[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: 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

* bug#37999: clang fails to pickup/supply startfiles to ld
  2019-11-04 20:31     ` Carl Dong
@ 2019-11-05  7:55       ` Mathieu Othacehe
  2019-11-07 16:23         ` Danny Milosavljevic
  2019-11-16 14:31         ` Mathieu Othacehe
  0 siblings, 2 replies; 9+ messages in thread
From: Mathieu Othacehe @ 2019-11-05  7:55 UTC (permalink / raw)
  To: Carl Dong; +Cc: 37999@debbugs.gnu.org


> 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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#37999: clang fails to pickup/supply startfiles to ld
  2019-11-05  7:55       ` Mathieu Othacehe
@ 2019-11-07 16:23         ` Danny Milosavljevic
  2019-11-16 14:31         ` Mathieu Othacehe
  1 sibling, 0 replies; 9+ messages in thread
From: Danny Milosavljevic @ 2019-11-07 16:23 UTC (permalink / raw)
  To: Mathieu Othacehe; +Cc: 37999@debbugs.gnu.org, Carl Dong

[-- 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 --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#37999: clang fails to pickup/supply startfiles to ld
  2019-11-05  7:55       ` Mathieu Othacehe
  2019-11-07 16:23         ` Danny Milosavljevic
@ 2019-11-16 14:31         ` Mathieu Othacehe
  1 sibling, 0 replies; 9+ messages in thread
From: Mathieu Othacehe @ 2019-11-16 14:31 UTC (permalink / raw)
  To: Carl Dong; +Cc: 37999-done@debbugs.gnu.org


Hello,

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

Mathieu

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2019-11-16 14:32 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2019-11-04 20:31     ` Carl Dong
2019-11-05  7:55       ` Mathieu Othacehe
2019-11-07 16:23         ` Danny Milosavljevic
2019-11-16 14:31         ` Mathieu Othacehe

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.