[1/1] package/go-native: add a new download only package for go compilers

The go-native is mainly for the aarch64 support since that was
added after the go-bootstrap written in C was dropped. So, to
get a cross compiler for go a host/native compiler needs to be
available to generate the setup for the needed target. This is
using the same go version as the expected cross-compiler to
keep the packages in sync. A specific version could be used.

Signed-off-by: Charles Hardin <ckhardin@gmail.com>
---
 package/Config.in.host           |  1 +
 package/go-native/Config.in.host | 12 ++++++++
 package/go-native/go-native.hash |  5 ++++
 package/go-native/go-native.mk   | 48 ++++++++++++++++++++++++++++++++
 package/go/Config.in.host        |  6 ++--
 package/go/go.mk                 | 12 +++++++-
 6 files changed, 81 insertions(+), 3 deletions(-)
 create mode 100644 package/go-native/Config.in.host
 create mode 100644 package/go-native/go-native.hash
 create mode 100644 package/go-native/go-native.mk

Hi Charles,

This is not necessary with this patch series:

https://patchwork.ozlabs.org/project/buildroot/list/?series=358451

We can correctly bootstrap on arm64.

On Fri, Jul 7, 2023 at 11:51 AM Charles Hardin <ckhardin@gmail.com> wrote:
>
> The go-native is mainly for the aarch64 support since that was
> added after the go-bootstrap written in C was dropped. So, to
> get a cross compiler for go a host/native compiler needs to be
> available to generate the setup for the needed target. This is
> using the same go version as the expected cross-compiler to
> keep the packages in sync. A specific version could be used.

Thanks,
Christian Stewart

Hi Charles,


On Fri, Jul 7, 2023 at 12:04 PM Christian Stewart <christian@aperture.us> wrote:
> This is not necessary with this patch series:
>
> https://patchwork.ozlabs.org/project/buildroot/list/?series=358451
>
> We can correctly bootstrap on arm64.

I should clarify: actually go bootstrap stage1 cannot work on arm64
(you're correct on this).

I had submitted this patch as well to use the host "go" in this case:

https://patchwork.ozlabs.org/project/buildroot/patch/20230215073256.186476-3-christian@paral.in/

Similar to how we use host gcc.

However, I understand that your series intends to add downloading the
binaries for the Go compiler to Buildroot as well.

This is potentially useful but I still submit that we need to merge
the above series updating to Go 1.20 and splitting the bootstrap into
two phases before merging the go-native series.

I'll start testing your patch as well.

Thanks,
Christian

> On Fri, Jul 7, 2023 at 11:51 AM Charles Hardin <ckhardin@gmail.com> wrote:
> >
> > The go-native is mainly for the aarch64 support since that was
> > added after the go-bootstrap written in C was dropped. So, to
> > get a cross compiler for go a host/native compiler needs to be
> > available to generate the setup for the needed target. This is
> > using the same go version as the expected cross-compiler to
> > keep the packages in sync. A specific version could be used.

Christian

On Fri, Jul 7, 2023 at 12:08 PM Christian Stewart <christian@aperture.us>
wrote:

> Hi Charles,
>
>
> On Fri, Jul 7, 2023 at 12:04 PM Christian Stewart <christian@aperture.us>
> wrote:
> > This is not necessary with this patch series:
> >
> > https://patchwork.ozlabs.org/project/buildroot/list/?series=358451
> >
> > We can correctly bootstrap on arm64.
>
> I should clarify: actually go bootstrap stage1 cannot work on arm64
> (you're correct on this).
>
> I had submitted this patch as well to use the host "go" in this case:
>
>
> https://patchwork.ozlabs.org/project/buildroot/patch/20230215073256.186476-3-christian@paral.in/
>
> Similar to how we use host gcc.
>
>
Weird - i was looking for a fix and never saw - perhaps i didn't have the
magic google search keywords. So, this was "our fix" to just get something
working specifically on a aarch64 builds. This is our annual timeline of
let's take our patches we have locally and send them upstream to see what
happens and see if we can drop our local patches in favor of upstream fixes.


> However, I understand that your series intends to add downloading the
> binaries for the Go compiler to Buildroot as well.
>
> This is potentially useful but I still submit that we need to merge
> the above series updating to Go 1.20 and splitting the bootstrap into
> two phases before merging the go-native series.
>
>
I just went for a quick and dirty to just use a native instead of doing the
bootstrap - we have a major issue in that we don't have many x86_64 build
systems anymore and we are having to move to aarch64 builds almost
exclusively. So, not having a way to get the compiler going was becoming a
headache.


> I'll start testing your patch as well.
>
>
This is not meant to replace - more of a - here is a way that worked for
us, if there is a better way that fits into buildroot then please just
merge that. Right now we don't have anything in the proper mainline so
everything is a deviation at this time.


> Thanks,
> Christian
>
> > On Fri, Jul 7, 2023 at 11:51 AM Charles Hardin <ckhardin@gmail.com>
> wrote:
> > >
> > > The go-native is mainly for the aarch64 support since that was
> > > added after the go-bootstrap written in C was dropped. So, to
> > > get a cross compiler for go a host/native compiler needs to be
> > > available to generate the setup for the needed target. This is
> > > using the same go version as the expected cross-compiler to
> > > keep the packages in sync. A specific version could be used.
>

Hi Charles,

On Fri, Jul 7, 2023, 1:05 PM Charles Hardin <ckhardin@gmail.com> wrote:

> Christian
>
> On Fri, Jul 7, 2023 at 12:08 PM Christian Stewart <christian@aperture.us>
> wrote:
>
>> Hi Charles,
>>
>>
>> On Fri, Jul 7, 2023 at 12:04 PM Christian Stewart <christian@aperture.us>
>> wrote:
>> > This is not necessary with this patch series:
>> >
>> > https://patchwork.ozlabs.org/project/buildroot/list/?series=358451
>> >
>> > We can correctly bootstrap on arm64.
>>
>> I should clarify: actually go bootstrap stage1 cannot work on arm64
>> (you're correct on this).
>>
>> I had submitted this patch as well to use the host "go" in this case:
>>
>>
>> https://patchwork.ozlabs.org/project/buildroot/patch/20230215073256.186476-3-christian@paral.in/
>>
>> Similar to how we use host gcc.
>>
>>
> Weird - i was looking for a fix and never saw - perhaps i didn't have the
> magic google search keywords. So, this was "our fix" to just get something
> working specifically on a aarch64 builds. This is our annual timeline of
> let's take our patches we have locally and send them upstream to see what
> happens and see if we can drop our local patches in favor of upstream fixes.
>
>
>> However, I understand that your series intends to add downloading the
>> binaries for the Go compiler to Buildroot as well.
>>
>> This is potentially useful but I still submit that we need to merge
>> the above series updating to Go 1.20 and splitting the bootstrap into
>> two phases before merging the go-native series.
>>
>>
> I just went for a quick and dirty to just use a native instead of doing
> the bootstrap - we have a major issue in that we don't have many x86_64
> build systems anymore and we are having to move to aarch64 builds almost
> exclusively. So, not having a way to get the compiler going was becoming a
> headache.
>

Ah - okay this makes sense. In this case I recommend using my patch to use
the host Go compiler to bootstrap the Go compiler.

This still compiles whatever version of Go buildroot has in the tree from
source using the host Go compiler to bootstrap.

Thomas, all; I do request that we merge the go 1.20 series and the "use
host compiler to bootstrap on unsupported architectures" patch asap as
these are significant blockers for some users (as seen here)

Thanks!

Christian