Date: Fri, 23 Apr 2021 23:54:33 -0600 (MDT)
From: Ariadne Conill <ariadne@dereferenced.org>
To: Roman Shaposhnik <roman@zededa.com>
cc: Ariadne Conill <ariadne@dereferenced.org>, 
    ~alpine/devel@lists.alpinelinux.org
Subject: Re: Alpine for riscv64
In-Reply-To: <CAMmSBy_heKqWRdp3efNfCO-Gcn7JSa6NovppSzR8jsL587uD3g@mail.gmail.com>
Message-ID: <8e69313-5b68-4274-c986-2861893e80d@dereferenced.org>
References: <CAMmSBy8PSwvk0krVHtf9k19-dRFa8xYKufb+ATmbswDoRNG-5Q@mail.gmail.com> <2f186144-b498-316-1e83-9092693c9d6@dereferenced.org> <CAMmSBy_heKqWRdp3efNfCO-Gcn7JSa6NovppSzR8jsL587uD3g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed

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