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?)
1. nghttp2 binary that is generated with TEXT relocations (not sure
what to do here)
2. failing to recognize a proper riscv64-alpine-linux-musl so I
have to force riscv64-linux-musl
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.
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.
Thanks,
Roman.
P.S. If you're curious what my next steps are - for EVE I need these
packages:
https://github.com/lf-edge/eve/blob/master/pkg/alpine/mirrors/3.13/main
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
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"
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.
Ariadne
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.