[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.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 64929@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 64929
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch