[bug#64929] gnu: gcc-toolchain: Create a 'bin/cc' symlink.

There are many projects that don't have a configure script that finds gcc.

Also makes it more symmetric with the clang-toolchain, that also does this.

* gnu/packages/commencement.scm (make-gcc-toolchain): Create the symlink.
---

i'm not sure what was the conclusion about this. clang-toolchain does
create a cc symlink, so i have mirrored what clang-toolchain does into
gcc-toolchain.

i thought i'll send this patch lying in my kludges branch, and
offer it either for rejection or inclusion, as you see fit.

 gnu/packages/commencement.scm | 6 ++++++
 1 file changed, 6 insertions(+)


base-commit: e43cbeafd1b632f39b08b3644af5230d5350a656
prerequisite-patch-id: 6793c8ad24215c5f14ce71a4741fff5f6ccd7eeb
prerequisite-patch-id: 3a8dd737d11f37987641af9bc7f512a0bb1a1591

> There are many projects that don't have a configure script that finds 
gcc.

> +                       ;; Create 'cc' so that one can use it as a drop-in
> +                       ;; replacement for the default tool chain and have
> +                       ;; configure scripts find the compiler.  Note that
> +                       ;; 'c++' is already present, no need to symlink it.
> +                       (symlink "gcc" (string-append out "/bin/cc"))

That doesn't work.  Sure, those configure scripts will find _a_ 
compiler, but it will be the _wrong_ compiler when cross-compiling, so 
for such packages you need to set CC=(cc-for-target) instead, which 
eliminates the need for 'cc'.  Furthermore, the lack of a ‘cc’ binary 
ensures that those configure scripts fail, which helps 
detecting/preventing this cross-compilation issue.

IOW, I think the true issue is the use of 'cc' in those configure 
scripts, not the lack of 'cc' in Guix.

(I have a patch at https://issues.guix.gnu.org/65426 for detecting this 
kind of compilation issue, albeit in #:make-flags instead instead of 
#:configure-flags and it doesn't look inside configure scripts.)

Also see <https://issues.guix.gnu.org/28629>, though that one is pretty 
useless because it doesn't _why_ the decision was made.

 > [...] Also makes it more symmetric with the clang-toolchain, that 
also does this.

If you are aiming for symmetry, I would instead propose removing 'cc' 
from clang-toolchain.  OTOH, cross-compilation in clang works somewhat 
differently (extra arguments instead of a separate binary IIUC), so 
perhaps Clang's cc is fine (assuming that the (equivalents of) Makefiles 
actually bother passing those extra arguments, which I doubt ...)

Best regards,
Maxime.

ok, i see why this won't work.

CC=(cc-for-target) is fine for packages, but the use-case that i'd like to facilitate is `guix shell gcc-toolchain some-other-deps` and then build a project manually from the opened shell.

any ideas how to help/handle that use-case without disrupting cross-compilation for packages?

Op 21-08-2023 om 16:30 schreef Attila Lendvai:
> ok, i see why this won't work.
> 
> CC=(cc-for-target) is fine for packages, but the use-case that i'd like to facilitate is `guix shell gcc-toolchain some-other-deps` and then build a project manually from the opened shell.
> 
> any ideas how to help/handle that use-case without disrupting cross-compilation for packages?
>

IIUC, gcc-toolchain isn't used for "guix build" (I'm not really sure 
though), so if that's your use case, your current patch would work 
without problems w.r.t. cross-compilation.  Rhetorical question: why 
didn't I think of this when writing my previous message?

However, (assuming my assumption about gcc-toolchain is correct), 
applying the patch would create a discrepancy between the build 
environment from "guix build/guix shell -D ..." and "guix shell 
gcc-toolchain more-deps", which isn't nice and is potentially confusing.

I was going to suggest that the solution would be to modify your script 
to look for TARGET-cc when cross-compiling, but while that would be an 
improvement it wouldn't solve anything as Guix doesn't have TARGET-cc.

For an alternate proposal (which I think has been proposed before, but I 
don't recall where), it might be possible to create 'symlink' packages 
"symlink-cc-gcc" and "symlink-cc-clang", that respectively have the 
cc->gcc and cc->clang symlink (also cc->clang should be removed from the 
clang package, otherwise there is a collision and a preference for clang).

(I'm thinking of Debian's alternative system, but simplified (no 
priorities!) and based on packages.)

For --with-c-toolchain (*) (**) and the cross-compilation issue I 
mentioned, these should be forbidden for use in Guix packages (as in, 
"guix lint" doesn't like it/not accepted in Guix proper, if some other 
channel does it anyway, it's not recommended, but also not really any of 
Guix' concern).

(*) I don't know if clang and cross-compilation is supported yet by 
--with-c-toolchain.
(**) though with-c-toolchain isn't truly a concern, as it could simply 
adjust the symlink inputs ...

(I have the impression that I previously was against such symlink 
packages, but I don't recall actually writing a message about it.)

Best regards,
Maxime Devos.

Hello,

On IRC Attila (I'm pretty sure) brought this to my attention. I don't
have much to add or feelings on this (I generally agree with the
reasoning for leaving out a cc link in gcc-toolchain directly) except:

On Mon, Aug 21, 2023 at 05:08 PM, Maxime Devos wrote:

> Op 21-08-2023 om 16:30 schreef Attila Lendvai:
>> ok, i see why this won't work.
>> CC=(cc-for-target) is fine for packages, but the use-case that i'd
>> like to facilitate is `guix shell gcc-toolchain some-other-deps` and
>> then build a project manually from the opened shell.
>> any ideas how to help/handle that use-case without disrupting
>> cross-compilation for packages?
>>
>
> IIUC, gcc-toolchain isn't used for "guix build" (I'm not really sure
> though), so if that's your use case, your current patch would work
> without problems w.r.t. cross-compilation.  Rhetorical question: why
> didn't I think of this when writing my previous message?
>
> However, (assuming my assumption about gcc-toolchain is correct),
> applying the patch would create a discrepancy between the build
> environment from "guix build/guix shell -D ..." and "guix shell
> gcc-toolchain more-deps", which isn't nice and is potentially
> confusing.
>
> I was going to suggest that the solution would be to modify your
> script to look for TARGET-cc when cross-compiling, but while that
> would be an improvement it wouldn't solve anything as Guix doesn't
> have TARGET-cc.
>
> For an alternate proposal (which I think has been proposed before, but
> I don't recall where), it might be possible to create 'symlink'
> packages "symlink-cc-gcc" and "symlink-cc-clang", that respectively
> have the cc->gcc and cc->clang symlink (also cc->clang should be
> removed from the clang package, otherwise there is a collision and a
> preference for clang).
>
> (I'm thinking of Debian's alternative system, but simplified (no
> priorities!) and based on packages.)
>

or something like our python-wrapper package. In other words, a package
to make things similar to other distros, just for a user that wants
their own environment like that.

Alternatively, I just wanted to note that in the --emulate-fhs option,
we do set up a 'cc' symlink, as part of "emulating" a more typical FHS
setup. I sort of just did that on my own since I thought it would be
useful for the times one wants the FHS shell. Anyway, that is an option,
though in a container you have to do more to set up your environment in
the first place.

John

> For --with-c-toolchain (*) (**) and the cross-compilation issue I
> mentioned, these should be forbidden for use in Guix packages (as in,
> "guix lint" doesn't like it/not accepted in Guix proper, if some other
> channel does it anyway, it's not recommended, but also not really any
> of Guix' concern).
>
> (*) I don't know if clang and cross-compilation is supported yet by
> --with-c-toolchain.
> (**) though with-c-toolchain isn't truly a concern, as it could simply
> adjust the symlink inputs ...
>
> (I have the impression that I previously was against such symlink
> packages, but I don't recall actually writing a message about it.)
>
> Best regards,
> Maxime Devos.