GNU bug report logs -
#37999
clang fails to pickup/supply startfiles to ld
Previous Next
Reported by: Carl Dong <contact <at> carldong.me>
Date: Wed, 30 Oct 2019 20:50:02 UTC
Severity: normal
Done: Mathieu Othacehe <m.othacehe <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 37999 in the body.
You can then email your comments to 37999 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org:
bug#37999; Package
guix.
(Wed, 30 Oct 2019 20:50:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Carl Dong <contact <at> carldong.me>:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org.
(Wed, 30 Oct 2019 20:50:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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 <at> 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 <at> carldong.me
"I fight for the users"
Information forwarded
to
bug-guix <at> gnu.org:
bug#37999; Package
guix.
(Thu, 31 Oct 2019 07:56:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 37999 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[0001-gnu-clang-from-llvm-Fix-linking.patch (text/x-diff, inline)]
From ac0cf4e25f9acdb02bee402b45a8f31a4830fcb7 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe <m.othacehe <at> 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
[Message part 3 (text/plain, inline)]
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 <at> 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 <at> carldong.me
> "I fight for the users"
Information forwarded
to
bug-guix <at> gnu.org:
bug#37999; Package
guix.
(Thu, 31 Oct 2019 13:17:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 37999 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-guix <at> gnu.org:
bug#37999; Package
guix.
(Thu, 31 Oct 2019 14:12:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 37999 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
This patch is a bit more viable that the previous one I think.
Mathieu
[0001-gnu-clang-from-llvm-Fix-set-glibc-file-names-phase.patch (text/x-diff, inline)]
From f126146880e3904f39728313dfc10288b51fc23a Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe <m.othacehe <at> 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
Information forwarded
to
bug-guix <at> gnu.org:
bug#37999; Package
guix.
(Thu, 31 Oct 2019 22:58:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 37999 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Mathieu Othacehe <m.othacehe <at> gmail.com> writes:
> From f126146880e3904f39728313dfc10288b51fc23a Mon Sep 17 00:00:00 2001
> From: Mathieu Othacehe <m.othacehe <at> 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.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#37999; Package
guix.
(Mon, 04 Nov 2019 20:32:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 37999 <at> debbugs.gnu.org (full text, mbox):
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 <at> carldong.me
"I fight for the users"
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, October 31, 2019 10:57 PM, Marius Bakke <mbakke <at> fastmail.com> wrote:
> Mathieu Othacehe m.othacehe <at> gmail.com writes:
>
> > From f126146880e3904f39728313dfc10288b51fc23a Mon Sep 17 00:00:00 2001
> > From: Mathieu Othacehe m.othacehe <at> 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.
Information forwarded
to
bug-guix <at> gnu.org:
bug#37999; Package
guix.
(Tue, 05 Nov 2019 07:56:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 37999 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-guix <at> gnu.org:
bug#37999; Package
guix.
(Thu, 07 Nov 2019 16:24:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 37999 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
[Message part 2 (application/pgp-signature, inline)]
Reply sent
to
Mathieu Othacehe <m.othacehe <at> gmail.com>:
You have taken responsibility.
(Sat, 16 Nov 2019 14:32:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Carl Dong <contact <at> carldong.me>:
bug acknowledged by developer.
(Sat, 16 Nov 2019 14:32:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 37999-done <at> debbugs.gnu.org (full text, mbox):
Hello,
I'm closing this one as you pushed the patch.
Mathieu
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 15 Dec 2019 12:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 132 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.