GNU bug report logs -
#47648
cc-for-target makes --with-c-toolchain unusable for some packages
Previous Next
To reply to this bug, email your comments to 47648 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#47648
; Package
guix
.
(Thu, 08 Apr 2021 00:41:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
raingloom <raingloom <at> riseup.net>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Thu, 08 Apr 2021 00:41:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I tried compiling lua with clang on a whim and found out about
cc-for-target. Not sure if that's the only instance of hardcoded gcc,
but it's certainly a prominent one.
What would be the idiomatic way to fix it? Detect clang dynamically? Or
move cc-for-target inside the build system module and make it available
at build time?
Information forwarded
to
bug-guix <at> gnu.org
:
bug#47648
; Package
guix
.
(Mon, 12 Apr 2021 09:48:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 47648 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, 2021-04-08 at 02:33 +0200, raingloom wrote:
> I tried compiling lua with clang on a whim and found out about
> cc-for-target. Not sure if that's the only instance of hardcoded gcc,
> but it's certainly a prominent one.
A little more information:
this is not specific to cc-for-target. Try searching for "CC=gcc".
Most uses of "CC=gcc" are incorrect when cross-compiling. When
cross-compiling, these should be "CC=ARCHITECTURE-linux-gnu-gcc" or
something like that. The "cc-for-target" procedure outputs the correct
string.
> What would be the idiomatic way to fix it? Detect clang dynamically? Or
> move cc-for-target inside the build system module and make it available
> at build time?
To avoid massive rebuilds, perhaps the procedure "cc-for-target" could be
replaced with a macro "cc-for-target" that accesses the native-inputs of
this-package to determine whether it should output "CC=gcc" /
"CC=ARCHITECTURE-linux-gnu-gcc" or "CC=clang" / "CC=ARCHITECTURE-linux-gnu-clang"?
Also, moving cc-for-taget to the build system module would require changing
existing package definitions:
,(string-append "CC=" (cc-for-target)) --> (string-append "CC=" (cc-for-target))
(string-append "CC=" ,(cc-for-target)) --> (string-append "CC=" (cc-for-targt))
Warning: I haven't tested whether this approach works with --with-c-toolchain.
Greetings,
Maxime.
[signature.asc (application/pgp-signature, inline)]
Severity set to 'important' from 'normal'
Request was from
Ludovic Courtès <ludo <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Fri, 16 Apr 2021 15:45:02 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 60 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.