GNU bug report logs

#47648 cc-for-target makes --with-c-toolchain unusable for some packages

PackageSource(s)Maintainer(s)
guix PTS Buildd Popcon
Reply or subscribe to this bug. View this bug as an mbox, status mbox, or maintainer mbox

Report forwarded to bug-guix@gnu.org:
bug#47648; Package guix. (Thu, 08 Apr 2021 00:41:02 GMT) (full text, mbox, link).


Acknowledgement sent to raingloom <raingloom@riseup.net>:
New bug report received and forwarded. Copy sent to bug-guix@gnu.org. (Thu, 08 Apr 2021 00:41:02 GMT) (full text, mbox, link).


Message #5 received at submit@debbugs.gnu.org (full text, mbox, reply):

From: raingloom <raingloom@riseup.net>
To: Guix Bugs <bug-guix@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@gnu.org:
bug#47648; Package guix. (Mon, 12 Apr 2021 09:48:01 GMT) (full text, mbox, link).


Message #8 received at 47648@debbugs.gnu.org (full text, mbox, reply):

From: Maxime Devos <maximedevos@telenet.be>
To: raingloom <raingloom@riseup.net>, 47648@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@gnu.org> to control@debbugs.gnu.org. (Fri, 16 Apr 2021 15:45:02 GMT) (full text, mbox, link).


Send a report that this bug log contains spam.


debbugs.gnu.org maintainers <help-debbugs@gnu.org>. Last modified: Sun Sep 8 03:52:00 2024; Machine Name: wallace-server

GNU bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.