MIME-Version: 1.0
References: <CAMmSBy8PSwvk0krVHtf9k19-dRFa8xYKufb+ATmbswDoRNG-5Q@mail.gmail.com>
 <2f186144-b498-316-1e83-9092693c9d6@dereferenced.org>
In-Reply-To: <2f186144-b498-316-1e83-9092693c9d6@dereferenced.org>
From: Roman Shaposhnik <roman@zededa.com>
Date: Fri, 23 Apr 2021 22:06:21 -0700
Message-ID: <CAMmSBy_heKqWRdp3efNfCO-Gcn7JSa6NovppSzR8jsL587uD3g@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"

Somehow I have a feeling that the mailing list ate my attachment --
can someone please confirm/deny?

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)

> > 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?

> > 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.

Got it!

Thanks,
Roman.

And here's the bootstrap.sh patch:

@@ -96,9 +96,10 @@ EXTRADEPENDS_TARGET="libgcc libstdc++ musl-dev"

 # ordered cross-build
 for PKG in fortify-headers linux-headers musl libc-dev pkgconf zlib \
-          openssl ca-certificates libmd libbsd libtls-standalone
busybox busybox-initscripts binutils make \
+          openssl ca-certificates libmd \
+          gmp mpfr4 mpc1 isl22 cloog libucontext binutils gcc \
+          libbsd libtls-standalone busybox busybox-initscripts make \
           apk-tools file \
-          gmp mpfr4 mpc1 isl22 cloog libucontext gcc \
           openrc alpine-conf alpine-baselayout alpine-keys
alpine-base patch build-base \
           attr libcap acl fakeroot tar \
           lzip abuild ncurses libedit openssh \
@@ -110,7 +111,7 @@ for PKG in fortify-headers linux-headers musl
libc-dev pkgconf zlib \
           libxml2 llvm10 community/rust \
           $KERNEL_PKG ; do

-       EXTRADEPENDS_TARGET="$EXTRADEPENDS_TARGET" \
+       EXTRADEPENDS_TARGET="$EXTRADEPENDS_TARGET"
EXTRADEPENDS_BUILD="libatomic gcc-$TARGET_ARCH g++-$TARGET_ARCH" \
        CHOST=$TARGET_ARCH BOOTSTRAP=bootimage APKBUILD=$(apkbuildname
$PKG) abuild -r

        case "$PKG" in
@@ -118,6 +119,11 @@ for PKG in fortify-headers linux-headers musl
libc-dev pkgconf zlib \
                # Additional implicit dependencies once built
                EXTRADEPENDS_TARGET="$EXTRADEPENDS_TARGET $PKG"
                ;;
+       gcc)
+               # After gcc full build, we get to have libatomic that
a low of packages require
+               # The reason we need gcc as well is because .so is
there, not in libatomic
+               EXTRADEPENDS_TARGET="libatomic gcc $EXTRADEPENDS_TARGET"
+               ;;
        build-base)
                # After build-base, that alone is sufficient
dependency in the target
                EXTRADEPENDS_TARGET="busybox $PKG"