[Buildroot] [PATCH 1/1] go: bump to 1.10

[Buildroot] [PATCH 1/1] go: bump to 1.10

[Christian Stewart]

This commit bumps the Go programming language to the 1.10 release.

Signed-off-by: Christian Stewart <christian@paral.in>
---
 package/go/go.hash | 2 +-
 package/go/go.mk   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/go/go.hash b/package/go/go.hash
index 445a0b7c20..73c1578d0b 100644
--- a/package/go/go.hash
+++ b/package/go/go.hash
@@ -1,2 +1,2 @@
 # From https://golang.org/dl/
-sha256	a4ab229028ed167ba1986825751463605264e44868362ca8e7accc8be057e993	go1.9.src.tar.gz
+sha256	f3de49289405fda5fd1483a8fe6bd2fa5469e005fd567df64485c4fa000c7f24	go1.10.src.tar.gz
diff --git a/package/go/go.mk b/package/go/go.mk
index 23facbdd81..4d55e16cc3 100644
--- a/package/go/go.mk
+++ b/package/go/go.mk
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-GO_VERSION = 1.9
+GO_VERSION = 1.10
 GO_SITE = https://storage.googleapis.com/golang
 GO_SOURCE = go$(GO_VERSION).src.tar.gz
 
-- 
2.13.6

[Buildroot] [PATCH 1/1] go: bump to 1.10

[Peter Korsgaard]

>>>>> "Christian" == Christian Stewart <christian@paral.in> writes:

 > This commit bumps the Go programming language to the 1.10 release.
 > Signed-off-by: Christian Stewart <christian@paral.in>

Committed to next, thanks.

It would be good if you could also add a hash for the license file.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1/1] go: bump to 1.10

[Peter Korsgaard]

>>>>> "Christian" == Christian Stewart <christian@paral.in> writes:

 > This commit bumps the Go programming language to the 1.10 release.
 > Signed-off-by: Christian Stewart <christian@paral.in>

This causes a number of build issues (strangely enough only from March
13th). Care to take a look?

http://autobuild.buildroot.net/?reason=host-go-1.1

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1/1] go: bump to 1.10

[Peter Korsgaard]

>>>>> "Peter" == Peter Korsgaard <peter@korsgaard.com> writes:

>>>>> "Christian" == Christian Stewart <christian@paral.in> writes:
 >> This commit bumps the Go programming language to the 1.10 release.
 >> Signed-off-by: Christian Stewart <christian@paral.in>

 > This causes a number of build issues (strangely enough only from March
 > 13th). Care to take a look?

 > http://autobuild.buildroot.net/?reason=host-go-1.1

Sorry, there actually were earlier failures (going back to Feb 20th, so
right after bumping the version).

What is common for all the failures is that the target arch == host arch
(x86-64) AND the C library is different (musl/uclibc-ng).

I did a quick test here and the reason is that host-go gets linked with
the target C library:

ls -lah build/host-go-1.10/bin/go
-rwxr-xr-x 1 peko peko 11M Apr  1 16:44 build/host-go-1.10/bin/go

./build/host-go-1.10/bin/go
zsh: no such file or directory: ./build/host-go-1.10/bin/go

ldd ./build/host-go-1.10/bin/go
        linux-vdso.so.1 (0x00007ffcd2bae000)
        libc.so.0 => not found

libc.so.0 is uClibc-ng.

Care to take a look?

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1/1] go: bump to 1.10

[Christian Stewart]

Hi Peter,

Peter Korsgaard <peter@korsgaard.com> writes:
> What is common for all the failures is that the target arch == host arch
> (x86-64) AND the C library is different (musl/uclibc-ng).
>
> I did a quick test here and the reason is that host-go gets linked with
> the target C library:
>
> ls -lah build/host-go-1.10/bin/go
> -rwxr-xr-x 1 peko peko 11M Apr  1 16:44 build/host-go-1.10/bin/go
>
> ./build/host-go-1.10/bin/go
> zsh: no such file or directory: ./build/host-go-1.10/bin/go
>
> ldd ./build/host-go-1.10/bin/go
>         linux-vdso.so.1 (0x00007ffcd2bae000)
>         libc.so.0 => not found
>
> libc.so.0 is uClibc-ng.
>
> Care to take a look?

I haven't had a chance to check on this yet. I'm puzzled why the
behavior would be different between glibc and uclibc.

Will do some testing when possible.

Best,
Christian Stewart

[Buildroot] [PATCH 1/1] go: bump to 1.10

[Peter Korsgaard]

>>>>> "Christian" == Christian Stewart <christian@paral.in> writes:

 > Hi Peter,
 > Peter Korsgaard <peter@korsgaard.com> writes:
 >> What is common for all the failures is that the target arch == host arch
 >> (x86-64) AND the C library is different (musl/uclibc-ng).
 >> 
 >> I did a quick test here and the reason is that host-go gets linked with
 >> the target C library:
 >> 
 >> ls -lah build/host-go-1.10/bin/go
 >> -rwxr-xr-x 1 peko peko 11M Apr  1 16:44 build/host-go-1.10/bin/go
 >> 
 >> ./build/host-go-1.10/bin/go
 >> zsh: no such file or directory: ./build/host-go-1.10/bin/go
 >> 
 >> ldd ./build/host-go-1.10/bin/go
 >> linux-vdso.so.1 (0x00007ffcd2bae000)
 >> libc.so.0 => not found
 >> 
 >> libc.so.0 is uClibc-ng.
 >> 
 >> Care to take a look?

 > I haven't had a chance to check on this yet. I'm puzzled why the
 > behavior would be different between glibc and uclibc.

It probably isn't, but if the host uses glibc and the target you build
for also uses glibc (and the same architecture), then it probably works
to link with the target libc instead of the host one.

 > Will do some testing when possible.

Thanks!

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1/1] go: bump to 1.10

[Christian Stewart]

Hi Peter,

Peter Korsgaard <peter@korsgaard.com> writes:
> It probably isn't, but if the host uses glibc and the target you build
> for also uses glibc (and the same architecture), then it probably works
> to link with the target libc instead of the host one.

Agreed, but it's maybe worth noting that I'm successfully compiling on
amd64 targeting arm and arm64.

Best,
Christian

[Buildroot] [PATCH 1/1] go: bump to 1.10

[Peter Korsgaard]

>>>>> "Christian" == Christian Stewart <christian@paral.in> writes:

 > Hi Peter,
 > Peter Korsgaard <peter@korsgaard.com> writes:
 >> It probably isn't, but if the host uses glibc and the target you build
 >> for also uses glibc (and the same architecture), then it probably works
 >> to link with the target libc instead of the host one.

 > Agreed, but it's maybe worth noting that I'm successfully compiling on
 > amd64 targeting arm and arm64.

I take it that the arm64 target uses glibc like your build machine,
E.G. similar to building for x86_64/glibc on a x86_64 machine?

-- 
Bye, Peter Korsgaard