GCC: Canadian Cross + Dynamic linker issues

GCC: Canadian Cross + Dynamic linker issues

[Ekaitz Zarraga]

Hi,

I've been struggling with GCC package definition for a while and I hope someone
can help me solve or improve what I think are issues in its definition.

I'm working on a R7RS-Small Scheme implementation that compiles to RISC-V
assembly and I'm finding many issues to create a RISC-V cross compiler.

Consider the following manifest file for my project, where I need a GCC for
a 32 bit RISC-V machine:


``` scheme
(use-modules (gnu packages cross-base)
             (gnu packages gcc)
             (gnu packages embedded))

(packages->manifest
  (let* ((triplet "riscv32-unknown-elf")
         (binutils (cross-binutils triplet)))
        (list
          binutils
          (cross-gcc triplet
                     #:xbinutils binutils
                     #:libc #f))))
```

The call to cross-gcc fails to find a dynamic linker and the installation
fails.

This happens because GCC package definition calls to the function
`glibc-dynamic-linker` in `gnu/packages/bootstrap.scm`, that contains a list of
possible triplets with their associated dynamic linker file name.

I don't really understand why does a generic GCC package need to call a
function from the bootstrap module by default. I can see why GCC takes a huge
part on the bootstrapping process of Guix but I think that kind of coupling is
compromising the flexibility of the generic GCC package. Please, correct me if
I'm wrong.

That said, in the past, I sent a patch[^patch] as a workaround because I saw
some references to AVR on the `glibc-dynamic-linker` that also used a fake
dynamic linker to avoid the function to fail but I got no response so I'm not
sure if the change makes any sense.

Digging further on the GCC package definition I found a note that says:

> ;; None of the flags below are needed when doing a Canadian cross.
> ;; TODO: Simplify this.

So I wonder if that's the source of the problems I'm finding here.

The `glibc-dynamic-linker` function is being used twice in the block preceded
by that comment and only once more below, in some patches we are applying on
top of the source code.

At this level I'm not sure if there's any way to "fix" GCC package definition
to be able to create cross-compilers or if I should create a separate package
for my specific use-case and forget about all this.

I would love to take part and try to simplify the GCC package description, but
as it is a fundamental package looks like a huge responsibility so I'd like to
have some guidance first.

Thanks,

Ekaitz

[^patch]: https://issues.guix.gnu.org/46059

Re: GCC: Canadian Cross + Dynamic linker issues

[Ekaitz Zarraga]

Let me please bump this thread a little bit, since I didn't get
any answer

> Hi,
>
> I've been struggling with GCC package definition for a while and I hope someone
> can help me solve or improve what I think are issues in its definition.
>
> I'm working on a R7RS-Small Scheme implementation that compiles to RISC-V
> assembly and I'm finding many issues to create a RISC-V cross compiler.
>
> Consider the following manifest file for my project, where I need a GCC for
> a 32 bit RISC-V machine:
>
>     (use-modules (gnu packages cross-base)
>                  (gnu packages gcc)
>                  (gnu packages embedded))
>
>     (packages->manifest
>
>       (let* ((triplet "riscv32-unknown-elf")
>              (binutils (cross-binutils triplet)))
>             (list
>               binutils
>               (cross-gcc triplet
>                          #:xbinutils binutils
>                          #:libc #f))))
>
>
> The call to cross-gcc fails to find a dynamic linker and the installation
> fails.
>
> This happens because GCC package definition calls to the function
> `glibc-dynamic-linker` in `gnu/packages/bootstrap.scm`, that contains a list of
> possible triplets with their associated dynamic linker file name.
>
> I don't really understand why does a generic GCC package need to call a
> function from the bootstrap module by default. I can see why GCC takes a huge
> part on the bootstrapping process of Guix but I think that kind of coupling is
> compromising the flexibility of the generic GCC package. Please, correct me if
> I'm wrong.
>
> That said, in the past, I sent a patch[^patch] as a workaround because I saw
> some references to AVR on the `glibc-dynamic-linker` that also used a fake
> dynamic linker to avoid the function to fail but I got no response so I'm not
> sure if the change makes any sense.
>
> Digging further on the GCC package definition I found a note that says:
>
> > ;; None of the flags below are needed when doing a Canadian cross.
> > ;; TODO: Simplify this.
>
> So I wonder if that's the source of the problems I'm finding here.
>
> The `glibc-dynamic-linker` function is being used twice in the block preceded
> by that comment and only once more below, in some patches we are applying on
> top of the source code.
>
> At this level I'm not sure if there's any way to "fix" GCC package definition
> to be able to create cross-compilers or if I should create a separate package
> for my specific use-case and forget about all this.
>
> I would love to take part and try to simplify the GCC package description, but
> as it is a fundamental package looks like a huge responsibility so I'd like to
> have some guidance first.
>
> Thanks,
>
> Ekaitz
>
> [^patch]: https://issues.guix.gnu.org/46059