GNU bug report logs - #47648
cc-for-target makes --with-c-toolchain unusable for some packages

Previous Next

Package: guix;

Reported by: raingloom <raingloom <at> riseup.net>

Date: Thu, 8 Apr 2021 00:41:02 UTC

Severity: important

To reply to this bug, email your comments to 47648 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


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

From: raingloom <raingloom <at> riseup.net>
To: Guix Bugs <bug-guix <at> gnu.org>
Subject: cc-for-target makes --with-c-toolchain unusable for some packages
Date: Thu, 8 Apr 2021 02:33:29 +0200
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):

From: Maxime Devos <maximedevos <at> telenet.be>
To: raingloom <raingloom <at> riseup.net>, 47648 <at> debbugs.gnu.org
Subject: Re: bug#47648: cc-for-target makes --with-c-toolchain unusable for
 some packages
Date: Mon, 12 Apr 2021 11:47:31 +0200
[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.