MIME-Version: 1.0
References: <CAMmSBy8PSwvk0krVHtf9k19-dRFa8xYKufb+ATmbswDoRNG-5Q@mail.gmail.com>
 <2f186144-b498-316-1e83-9092693c9d6@dereferenced.org> <CAMmSBy_heKqWRdp3efNfCO-Gcn7JSa6NovppSzR8jsL587uD3g@mail.gmail.com>
 <8e69313-5b68-4274-c986-2861893e80d@dereferenced.org>
In-Reply-To: <8e69313-5b68-4274-c986-2861893e80d@dereferenced.org>
From: Roman Shaposhnik <roman@zededa.com>
Date: Mon, 26 Apr 2021 15:04:24 -0700
Message-ID: <CAMmSBy_m4qP=JwQucFkadpJa7TPDEcv9ELyJNQP_Ht1dBGvhow@mail.gmail.com>
Subject: Re: Alpine for riscv64
To: Ariadne Conill <ariadne@dereferenced.org>
Cc: ~alpine/devel@lists.alpinelinux.org
Content-Type: text/plain; charset="UTF-8"

On Fri, Apr 23, 2021 at 10:54 PM Ariadne Conill
<ariadne@dereferenced.org> wrote:
>
> Hi,
>
> On Fri, 23 Apr 2021, Roman Shaposhnik wrote:
>
> > Somehow I have a feeling that the mailing list ate my attachment --
> > can someone please confirm/deny?
>
> No, it was present.
>
> > More comments inline:
> >
> > On Fri, Apr 23, 2021 at 9:25 PM Ariadne Conill <ariadne@dereferenced.org> wrote:
> >>
> >> Hello,
> >>
> >> On Fri, 23 Apr 2021, Roman Shaposhnik wrote:
> >>
> >>> Hi!
> >>>
> >>> long time lurker (and user of Alpine in Linux Foundation's Project EVE)
> >>> first time poster here!
> >>>
> >>> Over at Project EVE we're now embarking on a riscv64 port
> >>> and it would be super helpful if Alpine had that architecture supported.
> >>>
> >>> Since that's not that case, I started looking into it by using
> >>> aports/scripts/bootstrap.sh
> >>> and I have few things to report back.
> >>>
> >>> First good news -- after some small amount of patching of aports
> >>> I was able to run the script and get myself a riscv64 build environment.
> >>> I'm attaching the changes I had to make to accomplish this. These
> >>> are mostly workaround and I'd love to collaborate with folks interested
> >>> in riscv64 to at least clean these things up.
> >>>
> >>> The workarounds are roughly in the following categories:
> >>>   0. stale config.sub (what's an Alpine way of dealing with this?)
> >>
> >> Something like:
> >>
> >> prepare() {
> >>    default_prepare
> >>    update_config_sub
> >> }
> >
> > Awesome! Let me try it.
> >
> >>>   1. nghttp2 binary that is generated with TEXT relocations (not sure
> >>> what to do here)
> >>
> >> I'm not sure.  Do you have a build log?
> >
> > I am thinking that it actually would be helpful to build this on my GitHub
> > via GitHub actions so we can all have access to the logs (and missing
> > attachments ;-))
> >
> >>>   2. failing to recognize a proper riscv64-alpine-linux-musl so I
> >>> have to force riscv64-linux-musl
> >>
> >> What is failing to recogize that triplet?  LLVM?  We might need to add it
> >> there still.
> >
> > configure (but I haven't dug into why and what could be stale)
>
> I think based on your patch, update_config_sub is what is needed there
> too.  I'll be sure to update the bundled config.guess/config.sub when I
> cut another release of pkgconf.
>
> >>> And finally, here's the most interesting part in all of this -- it turns out
> >>> that an initial gcc is lacking libatomic.so and thus a few packages fail.
> >>> In order to workaround it I had to:
> >>>    1. restructure bootstrap.sh slightly so that a proper gcc gets built
> >>>    2. once #1 happens we add gcc and libatomic to build deps
> >>> Not sure what's up with this and would love to know if there's a simpler way.
> >>
> >> bootstrap.sh is intended to get a runtime environment up on a host, so you
> >> can build the rest of the distribution.  Accordingly, we don't presently
> >> build libatomic when crosscompiling, as we don't need it.
> >>
> >> But I think we can change that if it would be helpful.
> >
> > I get that -- but the problem is -- without libatomic in the initial gcc or the
> > trick that I play with the patch below -- it doesn't build. In fact, I
> > think patching
> > bootstrap.sh like that would be helpful anyway -- I can submit a PR.
> >
> > What do you all think?
>
> To clarify, are you using bootstrap.sh from v3.13 or from edge?  We only
> support bootstrap.sh on edge, as it's mainly intended to be an internal
> development tool.

Yes I am. Btw, I've pushed all my build steps into a single Dockerfile
    https://github.com/rvs/alpine-riscv64
so that:
  1. we can all be sure what we're talking about
  2. I actually end up with a container that I can use as riscv64
build environment

Btw, there's a GitHub action that is running the build so that build logs are
alway available:
    https://github.com/rvs/alpine-riscv64/actions/runs/787052838

Thanks,
Roman.