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 On Wednesday, October 28, 2020 at 11:12:18 AM UTC+1 hugo.c...@essensium.com wrote: > > > 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 > > > > On Fri, Oct 23, 2020 at 10:10 AM Hugo Cornelis <hugo.c...@essensium.com> > wrote: > >> >> 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 >> >> >> On Thu, Oct 22, 2020 at 5:40 PM Gerrit Binnenmars <gerritbi...@gmail.com> >> wrote: >> >>> >>> >>> 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: >>> >>>> >>>> >>>> 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 >>>> >>>> >>>> >>>> On Tue, Oct 20, 2020 at 6:20 AM 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/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 >>>>> >>>>> On Mon, Oct 19, 2020 at 2:06 PM Gerrit Binnenmars >>>>> <gerritbi...@gmail.com> wrote: >>>>> > >>>>> > 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) >>>>> >>>>> 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 >>>>> >>>>> -- >>>>> 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 >>>>> >>>>> <https://groups.google.com/d/msgid/golang-nuts/5f8e657e.1c69fb81.3e6dc.0cf4%40mx.google.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> 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/ee3608cf-b4e8-4d6e-b7bf-c2c3c0422feen%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/golang-nuts/ee3608cf-b4e8-4d6e-b7bf-c2c3c0422feen%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/cab0ff1d-ed10-41bc-b7e3-1082e98eb8c7n%40googlegroups.com.
