gccgo problem compiling go from source

[Gerrit Binnenmars]

Hello,

I used crosstool-ng successfully to build a go compiler for ppc e500.
Unfortunately go build does not support ppc therefore go needs to be
build from source using the amd64 gccgo compiler that I also build
with crosstool-ng.

Compiling go from source fails:
Problem: undefined name stdpkg in internal/goroot/gccgo.go

I included the output of my build script below. Any help or tips are welcome.

With kind regards,

Gerrit Binnenmars

Info:
This is crosstool-NG version 1.24.0.191_364ed7a
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/maintain/.cache/go-build"
GOENV="/home/maintain/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/maintain/gonew/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/maintain/gonew"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/maintain/x-tools/x86_64-e500-linux-gnu/x86_64-e500-linux-gnu/sysroot/lib"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/maintain/x-tools/x86_64-e500-linux-gnu/x86_64-e500-linux-gnu/sysroot/lib/pkg/tool/linux_amd64"
GCCGO="/home/maintain/x-tools/x86_64-e500-linux-gnu/bin/gccgo"
AR="ar"
CC="/home/maintain/x-tools/x86_64-e500-linux-gnu/bin/gcc"
CXX="/home/maintain/x-tools/x86_64-e500-linux-gnu/bin/g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="--with-sysroot=/home/maintain/x-tools/x86_64-e500-linux-gnu/x86_64-e500-linux-gnu/sysroot"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=/tmp/go-build355977706=/tmp/go-build
-gno-record-gcc-switches"
go version go1.15.2 linux/amd64
gccgo (GCC) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

WORK=/tmp/go-build273889551
mkdir -p $WORK/b100/
cd $WORK
/home/maintain/x-tools/x86_64-e500-linux-gnu/bin/gccgo
-fgo-importcfg=/dev/null -c -x c - -o /dev/null || true
cd /home/maintain/gonew/src/internal/goroot
/home/maintain/x-tools/x86_64-e500-linux-gnu/bin/gccgo -c -g -m64
-fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches
-fgo-pkgpath=internal/goroot -o $WORK/b100/_go_.o -I
$WORK/b100/_importcfgroot_ ./gccgo.go
mkdir -p $WORK/b027/
mkdir -p $WORK/b027/_importcfgroot_/cmd/go/internal
ln -s /home/maintain/.cache/go-build/ad/ade44815e7af8b7305b2db4099ec5b08aafcbd6e374a2c13d8e99c2986ca93c6-d
$WORK/b027/_importcfgroot_/cmd/go/internal/libauth.a
ln -s /home/maintain/.cache/go-build/d2/d26f05f163d86aecfadfbb952dfef9a314aa1c84c23fddd39bce127ccc85d101-d
$WORK/b027/_importcfgroot_/cmd/go/internal/libcfg.a
mkdir -p $WORK/b027/_importcfgroot_/cmd/internal
ln -s /home/maintain/.cache/go-build/2f/2f6811b0804c481edbfd9952d1aac22414f84ee1aec229218b03956bf3f9aa7a-d
$WORK/b027/_importcfgroot_/cmd/internal/libbrowser.a
cd /home/maintain/gonew/src/cmd/go/internal/web
/home/maintain/x-tools/x86_64-e500-linux-gnu/bin/gccgo -c -g -m64
-fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches
-fgo-pkgpath=cmd/go/internal/web -o $WORK/b027/_go_.o -I
$WORK/b027/_importcfgroot_ ./api.go ./http.go ./url.go ./url_other.go
# internal/goroot
src/internal/goroot/gccgo.go:24:10: error: reference to undefined name 'stdpkg'
   24 |   return stdpkg[path]
      |          ^
# cmd/go/internal/web
src/cmd/go/internal/web/api.go:92:45: error: reference to undefined
field or method 'Redacted'
   92 |   return nil, fmt.Errorf("reading %s: %v", u.Redacted(), err)  

[Ian Lance Taylor]

It looks like you are using the "go" program to build the gccgo
standard library. That doesn't work. The gccgo standard library must
be built as part of GCC, using the usual configure/make commands used
to build GCC itself. When configuring GCC, use --enable-languages=go.

Ian

[gerritbinnenmars]

Hello Ian,

Thanks for the quick reaction. It seems my request was not clear.

What I am doing is the other way around: using gccgo to build the "go" cmd.

So clone the "go" source from github and then go build -compiler gccgo ./cmd/go

Gerrit

-------- Oorspronkelijk bericht --------

Van: Ian Lance Taylor <ia...@golang.org>

Datum: 20-10-20 04:25 (GMT+01:00)

Aan: Gerrit Binnenmars <gerritbi...@gmail.com>

Cc: golang-nuts <golan...@googlegroups.com>

Onderwerp: Re: [go-nuts] gccgo problem compiling go from source

[fge...@gmail.com]

On 10/20/20, gerritbinnenmars <gerritbi...@gmail.com> wrote:
> Hello Ian,Thanks for the quick reaction. It seems my request was not
> clear.What I am doing is the other way around: using gccgo to build the "go"
> cmd.So clone the "go" source from github and then go build -compiler gccgo
> ./cmd/goGerrit

Assuming you are trying to get the compiler available on
github.com/golang/go (golang.org/dl) working on a hardware with ppc
e500 (en.wikipedia.org/wiki/PowerPC_e500) by cross compiling it with
gccgo running on linux/amd64, that won't work.

gccgo and github.com/golang/go are 2 different compilers running on
different hardware and os platforms, supporting different sets of
hardware and os platforms.

After looking at the list of supported platforms on build.golang.org
and looking at the golang-nuts and golang-dev mailing list archives, I
can't see the ppc e500 as a supported hardware platform for the go
compiler (available on golang.org/dl or github.com/golang/go .)
Getting a compiler to support a new platform or porting a compiler to
a new platform are usually non-trivial processes.
At this stage you'll probably want to use the gccgo compiler if that's working.
(Also you'll maybe find this useful:
https://github.com/golang/go/wiki/PortingPolicy )

[Hugo Cornelis]

Hi Gerrit,

If I understand correctly, I believe you try to cross-compile Go applications to the PowerPC e500 architecture and as a first step you are porting Go to this architecture.

We recently ported Go applications such as Docker and its tools to architectures not supported by upstream Go, but with an approach quite different from yours (if I understood well).

The procedure we follow, is:

1. Build the gccgo cross-toolchain with Buildroot: Buildroot currently builds a toolchain by first building a gcc-initial, then proceeding to build a gcc-final.  We had to insert a new gcc compilation stage before gcc-final can build the gccgo cross-compiler.  This additional gcc compilation stage makes go-tools available in the native environment that are required for building the gccgo cross-compiler tools when gcc-final is built.  If I understand well this may be an important part of the solution to your problem.

2. Patch the Buildroot environment to invoke gccgo as the compiler, rather than gc, for compiling Go applications.  We are planning to upstream this and the previous step to Buildroot in the coming months.

3. Implement Go system call bindings: The sys package of the Go runtime implements system call bindings as part of gccgo (so part of gcc-final), the golang-sys/unix package is (can be) shipped in the folder golang-sys/unix of the application you want to build (this is Docker and tools in our case).  The golang-sys package needs to be patched in each application to produce correct system call bindings for your target environment (so the PowerPC e500 in your case).  Most of our development time was spent in this last step (it is tricky).

Using this procedure we have ported Docker and its dependencies and tools to several ppc 32 bit architectures.

I hope this helps.

Hugo

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/5f8e657e.1c69fb81.3e6dc.0cf4%40mx.google.com.

[David Riley]

On Oct 20, 2020, at 2:38 AM, fge...@gmail.com wrote:
>
> After looking at the list of supported platforms on build.golang.org
> and looking at the golang-nuts and golang-dev mailing list archives, I
> can't see the ppc e500 as a supported hardware platform for the go
> compiler (available on golang.org/dl or github.com/golang/go .)
> Getting a compiler to support a new platform or porting a compiler to
> a new platform are usually non-trivial processes.
> At this stage you'll probably want to use the gccgo compiler if that's working.
> (Also you'll maybe find this useful:
> https://github.com/golang/go/wiki/PortingPolicy )

Yes, the biggest thing you'll run into is that support for 32-bit (and, IIRC, big-endian) PowerPC is long gone from the Go compiler. Someone else on the golang-dev list was working on a port to a different embedded-ish 32-bit PPC implementation (440, if memory serves, but it often doesn't). You might want to check there to see if you can collaborate. There is also this tracking issue, which you may find instructive: https://github.com/golang/go/issues/22885

Of note to non-PPC people: the eXXX cores are generally similar to older commercial PowerPCs (i.e. the e300 was a derivative of the 603e, the e500 is somewhat similar to the 750/G3, but is more advanced). Support for specific cores is not quite as important as support for the overall ISA unless you are building an operating system, where they can differ greatly on the low-level details.

Personally, I'd love to see 32-bit PPC support reinstated because I have a few boards I'd love to use with Net/OpenBSD and Go, but I don't have the time right now and it's not of commercial interest to me, so I can't get funding for it.


- Dave

[Gerrit Binnenmars]

Hello Hugo,

You are correct, what I try is to cross-compile a go application (in this case Mender client) for the ppc platform (e500 on a MFC8555 processor).

1. I used crosstool-ng instead of buildroot. It has support for "go" as experimental language and as result a gccgo compiler is build and also a libgo library.

2. The mender client is normally build with: go build client_dir what I do is: env GOOS=linux GOARCH=ppc go build -compiler gccgo client_dir
Than go complains as explained that ppc is a not supported architecture.
Unfortunately the crosstool-ng tooling thus not deliver a new go. I read somewhere that recompiling go with a gccgo compiler might solve this. (so besides the ppc version of ggcgo I also used crosstool-ng to build an x86_64 (amd64) version.

3. Interesting approach, I don't completely understand it yet but will investigate it further.

Is it possible to use a Makefile approach with gccgo instead of go build?

[Gerrit Binnenmars]

I referred to this link on the internet: https://github.com/golang/go/wiki/GccgoCrossCompilation#build-a-cross-gccgo-aware-version-of-the-go-tool

[Ian Lance Taylor]

On Tue, Oct 20, 2020 at 8:17 AM Gerrit Binnenmars
<gerritbi...@gmail.com> wrote:
>
> You are correct, what I try is to cross-compile a go application (in this case Mender client) for the ppc platform (e500 on a MFC8555 processor).
> 1. I used crosstool-ng instead of buildroot. It has support for "go" as experimental language and as result a gccgo compiler is build and also a libgo library.
> 2. The mender client is normally build with: go build client_dir what I do is: env GOOS=linux GOARCH=ppc go build -compiler gccgo client_dir
> Than go complains as explained that ppc is a not supported architecture.
> Unfortunately the crosstool-ng tooling thus not deliver a new go. I read somewhere that recompiling go with a gccgo compiler might solve this. (so besides the ppc version of ggcgo I also used crosstool-ng to build an x86_64 (amd64) version.
> 3. Interesting approach, I don't completely understand it yet but will investigate it further.
>
> Is it possible to use a Makefile approach with gccgo instead of go build?

There is some misunderstanding here.

There are two different Go compilers here: gc and gccgo. The gc
compiler does not support 32-bit PPC. There is no way to build the gc
compiler such that it will support 32-bit PPC. The gccgo compiler
does support 32-bit PPC. If you want to build Go programs for 32-bit
PPC, you should build and use the gccgo compiler. You should not be
using the gc compiler at all. When you build gccgo for 32-bit PPC,
you will get a version of the go tool that builds programs for 32-bit
PPC.

You say that using crosstool-ng does not give you a go tool. That
seems like a bug in crosstool-ng. You could try checking for
something like ppc-linux-gnu-go.

Ian

[Gerrit Binnenmars]

Ian, thanks for clearing that up. Will have another look at crosstool-ng.

[Gerrit Binnenmars]

Hello Hugo,

I did not succeed in getting crosstool-ng produce a go tool. Instead I adapted the source of the "normal" go tool and simply removed the check and added a fmt.Fprintf instead. It shows that even with go build -compiler gccgo the test is first called with the gc compiler and then with the gccgo compiler. So the test will always fail. I assume I still am doing something wrong but don't understand what.

Meanwhile with the adapted go tool I can build the mender client application with the ppc gccgo compiler. Next problem is the missing support for ppc in golang.org/x/sys/unix.

I also noticed that the community is interested in this: https://github.com/golang/go/issues/37443

Are you willing to share your unix package for ppc 32 bit architectures?

With regards, Gerrit

On Tuesday, October 20, 2020 at 9:52:17 AM UTC+2 hugo.c...@essensium.com wrote:

[Hugo Cornelis]

Hi Gerrit,

Yes, that was the plan, but it looks like powerpc support was already added to the sys/unix package last week.

When we were working on this package we first had several subtle and difficult to debug problems.  As part of debugging, we developed unit tests for validation of some of the system call bindings on powerpc using Qemu and a physical device.

I still plan to check the differences between our version of these bindings and the upstream version and check if this could result in problems (from quickly looking at the commits I can say that our bindings should differ from the upstream version, but I have no idea about the impact).

I will get back to this next week and post here what I find.

Hugo

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/ee3608cf-b4e8-4d6e-b7bf-c2c3c0422feen%40googlegroups.com.

[Hugo Cornelis]

Hi all,

I have set up a github repository with the system call bindings for powerpc that we developed over the last months.

https://github.com/hcornelis/golang-sys

Branch 'ppc-system-calls-v1'.

I compared the system call bindings that are available from https://github.com/golang/go/issues/37443 and the system call bindings that we developed for running Docker on powerpc 32 bit based systems.

The status and differences can be summarized as:

1. We mapped a few system call bindings to call the 64 bit variant of the system call (eg. fstat).  This was necessary for our applications (Docker) to work.

2. Our generated system call binding set is larger.  I assume because of differences in the used kernel header files and used options to generate the system call bindings.

3. I also implemented changes in the scripts that generate the structs of the bindings.  For instance the epoll event struct had wrong alignment for some of its members in our first version of the bindings, so this was corrected by specific updates in the generator scripts (in unix/mkpost.go).  There was also a problem with Statfs_t struct.

4. I am not an expert wrt cgo, but if I understand correctly, through the use of the cgo tool that is distributed with gccgo and knows ppc, we avoided small problems with cgo invocation.

5. I believe (all) the patches we did to the generator script 'mkall.go' are superseded by the upstream patches.

Regards,

Hugo

[Mirza Krak]

On Tuesday, October 20, 2020 at 9:52:17 AM UTC+2 hugo.c...@essensium.com wrote:

Hi Gerrit,

If I understand correctly, I believe you try to cross-compile Go applications to the PowerPC e500 architecture and as a first step you are porting Go to this architecture.

We recently ported Go applications such as Docker and its tools to architectures not supported by upstream Go, but with an approach quite different from yours (if I understood well).

The procedure we follow, is:

1. Build the gccgo cross-toolchain with Buildroot: Buildroot currently builds a toolchain by first building a gcc-initial, then proceeding to build a gcc-final.  We had to insert a new gcc compilation stage before gcc-final can build the gccgo cross-compiler.  This additional gcc compilation stage makes go-tools available in the native environment that are required for building the gccgo cross-compiler tools when gcc-final is built.  If I understand well this may be an important part of the solution to your problem.

2. Patch the Buildroot environment to invoke gccgo as the compiler, rather than gc, for compiling Go applications.  We are planning to upstream this and the previous step to Buildroot in the coming months.

Are these Buildroot changes available in a public repo? I have some interest in this, and was planning on doing something very similar in Buildroot, but if someone has already done, I would rather base any work on top of that.

Best Regards,

Mirza

 

[Gerrit Binnenmars]

Hello,

Hugo thanks for sharing your repo, I cloned the repo. Set the environment variables GOOS and GOARCH and called mkall.sh in the unix directory.

The result is a generate:linux docker image and an _obj/_cgo_.o file in the unix directory next to a number of go files.

So far this is as expected?

Are there any plans to get it in the official golang/sys package?

I copied the resulting unix directory to the mender client directory and called the go build command of mender.

This yielded:

+ env CGO_ENABLED=1 /home/maintain/crosstool-ng/crosstool-ng/.build/src/gcc-10.2.0/libgo/go/xgo build -work -p 1 -x -compiler gccgo -o mender_client_ppc ./src/github.com/mendersoftware/mender/client
+ tee log.txt
GOARCH ppc compiler gc  /* extra printf from xgo tool */

WORK=/tmp/go-build666945780
GOARCH ppc compiler gccgo /* extra printf from xgo tool */

src/github.com/mendersoftware/mender/vendor/github.com/sirupsen/logrus/terminal_check_unix.go:6:8: found packages unix (affinity_linux.go) and runtime (zsocket_definitions1_linux_ppc.go) in /home/maintain/mender/src/src/github.com/mendersoftware/mender/vendor/golang.org/x/sys/unix

There is no error message but also no build result and it seems like go build stops.

I have no idea how to continue. Any ideas?

The mender client had a go.mod with: golang.org/x/sys v0.0.0-20191120155948-bd437916bb0e

With regards, Gerrit

[Hugo Cornelis]

Hi Mirza,

These patches are not yet available in a public repository and they will need more work before they can be upstreamed.  We hope to upstream our patches to Buildroot before the end of the year.

I can check if it is possible to make these changes already available on Github.

Regards,

Hugo

 

 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/40449fcb-2545-42d9-8ae2-20bdee5eb02fn%40googlegroups.com.

[Hugo Cornelis]

Hi Gerrit,

On Mon, Nov 9, 2020 at 8:42 PM Gerrit Binnenmars <gerritbi...@gmail.com> wrote:

Hugo thanks for sharing your repo, I cloned the repo. Set the environment variables GOOS and GOARCH and called mkall.sh in the unix directory.

The result is a generate:linux docker image and an _obj/_cgo_.o file in the unix directory next to a number of go files.

So far this is as expected?

Yes, that is correct.

However some of the generated files are unnecessary.  For instance the file zsocket_definitions1_linux_ppc.go that you mention is unnecessary.

This file is an artefact that was generated by trial and error during development on the system call bindings.  It is unnecessary, causes confusion and should be removed in the future.

 

Are there any plans to get it in the official golang/sys package?

Yes.  I plan to use Gerrit to comment on the upstream developments that implement the support for powerpc.

I copied the resulting unix directory to the mender client directory and called the go build command of mender.

This yielded:

+ env CGO_ENABLED=1 /home/maintain/crosstool-ng/crosstool-ng/.build/src/gcc-10.2.0/libgo/go/xgo build -work -p 1 -x -compiler gccgo -o mender_client_ppc ./src/github.com/mendersoftware/mender/client
+ tee log.txt
GOARCH ppc compiler gc  /* extra printf from xgo tool */

WORK=/tmp/go-build666945780
GOARCH ppc compiler gccgo /* extra printf from xgo tool */

src/github.com/mendersoftware/mender/vendor/github.com/sirupsen/logrus/terminal_check_unix.go:6:8: found packages unix (affinity_linux.go) and runtime (zsocket_definitions1_linux_ppc.go) in /home/maintain/mender/src/src/github.com/mendersoftware/mender/vendor/golang.org/x/sys/unix

I would remove the file 'zsocket_definitions1_linux_ppc.go' from the build directory.

When building docker-engine with Buildroot, the final built Docker daemon is found in a 'bin' directory inside the 'output/build' directory.

I don't know anything about mender or how it is built, maybe the final executables are also to be found somewhere inside a 'bin' directory.

I hope this helps.

Regards,

Hugo

 

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/cab0ff1d-ed10-41bc-b7e3-1082e98eb8c7n%40googlegroups.com.

[Mirza Krak]

On Tue, Nov 10, 2020 at 10:06 AM Hugo Cornelis
<hugo.c...@essensium.com> wrote:
>
> Hi Mirza,
>
> On Thu, Nov 5, 2020 at 3:18 PM 'Mirza Krak' via golang-nuts <golan...@googlegroups.com> wrote:
>>
>> On Tuesday, October 20, 2020 at 9:52:17 AM UTC+2 hugo.c...@essensium.com wrote:
>>>
>>> 1. Build the gccgo cross-toolchain with Buildroot: Buildroot currently builds a toolchain by first building a gcc-initial, then proceeding to build a gcc-final. We had to insert a new gcc compilation stage before gcc-final can build the gccgo cross-compiler. This additional gcc compilation stage makes go-tools available in the native environment that are required for building the gccgo cross-compiler tools when gcc-final is built. If I understand well this may be an important part of the solution to your problem.
>>>
>>> 2. Patch the Buildroot environment to invoke gccgo as the compiler, rather than gc, for compiling Go applications. We are planning to upstream this and the previous step to Buildroot in the coming months.
>>
>>
>> Are these Buildroot changes available in a public repo? I have some interest in this, and was planning on doing something very similar in Buildroot, but if someone has already done, I would rather base any work on top of that.
>>
>> Best Regards,
>> Mirza
>
>
> These patches are not yet available in a public repository and they will need more work before they can be upstreamed. We hope to upstream our patches to Buildroot before the end of the year.

I am currently involved with a project with similar timelines, or the
goal would be to have something upstream before the 2021.02 Buildroot
release which would be an LTS and the plan is to start working on this
soon. And as I mentioned, I would rather collaborate then re-doing
work that is already done.

My interest is primarily to compile for ppc64 e5500 so I hope to avoid
the sys/unix issues that exist for ppc32.

> I can check if it is possible to make these changes already available on Github.

Would be great!

Best Regards,
Mirza