[PATCH] gnu: gcc-toolchain: Create a 'bin/cc' symlink.

  • Open
  • quality assurance status badge
Details
4 participants
  • Attila Lendvai
  • Attila Lendvai
  • John Kehayias
  • Maxime Devos
Owner
unassigned
Submitted by
Attila Lendvai
Severity
normal
A
A
Attila Lendvai wrote on 29 Jul 2023 13:50
(address . guix-patches@gnu.org)(name . Attila Lendvai)(address . attila@lendvai.name)
dd5d375b64b71dd138fb37fc1714628f029e85f3.1690631428.git.attila@lendvai.name
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(+)

Toggle diff (23 lines)
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index fe6f025257..fceda97ad5 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -3554,6 +3554,12 @@ (define* (make-gcc-toolchain gcc
((_ . directory) directory))
%build-inputs))
+ ;; 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"))
+
(union-build (assoc-ref %outputs "debug")
(list (assoc-ref %build-inputs
"libc-debug")))

base-commit: e43cbeafd1b632f39b08b3644af5230d5350a656
prerequisite-patch-id: 6793c8ad24215c5f14ce71a4741fff5f6ccd7eeb
prerequisite-patch-id: 3a8dd737d11f37987641af9bc7f512a0bb1a1591
--
2.40.1
M
M
Maxime Devos wrote on 21 Aug 2023 15:40
(address . 64929@debbugs.gnu.org)(name . Attila Lendvai)(address . attila@lendvai.name)
bbbb030f-d73b-e8e1-1790-5cd577236495@telenet.be
Toggle quote (1 lines)
> There are many projects that don't have a configure script that finds
gcc.
Toggle quote (5 lines)
> + ;; 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/65426for 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.
Attachment: OpenPGP_0x49E3EE22191725EE.asc
Attachment: OpenPGP_signature
A
A
Attila Lendvai wrote on 21 Aug 2023 16:30
(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 64929@debbugs.gnu.org)
pcKZHfrO5IF04jMS67HDb2tqvN8rIEZcbcblAuM2fjUZ0OJQL4GQko4SyFRuY6JJ06rCNOZeA4S1Gs9wrtu9IyN2MLjGtMmWZQXhDXxkf90=@lendvai.name
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?

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“He not busy being born is busy dying.”
— Bob Dylan (1941–), lyrics of 'It’s Alright, Ma'
M
M
Maxime Devos wrote on 21 Aug 2023 17:08
(name . Attila Lendvai)(address . attila@lendvai.name)(address . 64929@debbugs.gnu.org)
1ccea740-deb5-2032-b02f-1e46547d7624@telenet.be
Op 21-08-2023 om 16:30 schreef Attila Lendvai:
Toggle quote (6 lines)
> 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.
Attachment: OpenPGP_0x49E3EE22191725EE.asc
Attachment: OpenPGP_signature
J
J
John Kehayias wrote on 28 Feb 21:59 +0100
Re: [bug#64929] [PATCH] gnu: gcc-toolchain: Create a 'bin/cc' symlink.
(name . Maxime Devos)(address . maximedevos@telenet.be)
87a5nk71a1.fsf@protonmail.com
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:

Toggle quote (36 lines)
> 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

Toggle quote (16 lines)
> 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.
?