Date: Fri, 23 Apr 2021 22:25:38 -0600 (MDT)
From: Ariadne Conill <ariadne@dereferenced.org>
To: Roman Shaposhnik <roman@zededa.com>
cc: ~alpine/devel@lists.alpinelinux.org
Subject: Re: Alpine for riscv64
In-Reply-To: <CAMmSBy8PSwvk0krVHtf9k19-dRFa8xYKufb+ATmbswDoRNG-5Q@mail.gmail.com>
Message-ID: <2f186144-b498-316-1e83-9092693c9d6@dereferenced.org>
References: <CAMmSBy8PSwvk0krVHtf9k19-dRFa8xYKufb+ATmbswDoRNG-5Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed

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
}

>   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?

>   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.

>
> 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.

> In general, as I said -- I'd love to know if anyone else is also interested
> in riscv64 port and what's the best way to collaborate on that.

Drew DeVault was working on riscv64, but I'm not sure if he still is 
working on it.  We found that running on physical hardware would be too 
slow (the builder would have issues keeping up with the other ones).

So an option might be to do something with qemu.  The Alpine community has 
some experience with that via postmarketOS and the initial mips64 port.

Ariadne