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

['Mirza Krak' via golang-nuts]

On Tue, Nov 10, 2020 at 10:06 AM Hugo Cornelis
 wrote:
>
> Hi Mirza,
>
> On Thu, Nov 5, 2020 at 3:18 PM 'Mirza Krak' via golang-nuts 
>  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

-- 
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/CADHdJwBcDpKmwbJuB9zQbiV3KrUFdiHkVpkVhjoW%3D0iaCxti9w%40mail.gmail.com.

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

[Hugo Cornelis]

rpc 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 
>>> 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

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

[Hugo Cornelis]

Hi Mirza,

On Thu, Nov 5, 2020 at 3:18 PM 'Mirza Krak' via golang-nuts <
golang-nuts@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 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+unsubscr...@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
> 
> .
>

-- 
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/CAARrXCTgSm5KA7zJ4O41AHzBuQSP0APVjZO18ZYqE7eNdUxQXQ%40mail.gmail.com.

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

[Gerrit Binnenmars]

; 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  
>>>> 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  
>>>>> Datum: 20-10-20 04:25 (GMT+01:00) 
>>>>> Aan: Gerrit Binnenmars  
>>>>> Cc: golang-nuts  
>>>>> Onderwerp: Re: [go-nuts] gccgo problem compiling go from source 
>>>>>
>>>>> On Mon, Oct 19, 2020 at 2:06 PM Gerrit Binnenmars
>>>>>  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
>>>>>

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

['Mirza Krak' via golang-nuts]

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
 

-- 
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/40449fcb-2545-42d9-8ae2-20bdee5eb02fn%40googlegroups.com.

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

[Hugo Cornelis]

t;>>
>>> 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 
>>> 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 
>>>> Datum: 20-10-20 04:25 (GMT+01:00)
>>>> Aan: Gerrit Binnenmars 
>>>> Cc: golang-nuts 
>>>> Onderwerp: Re: [go-nuts] gccgo problem compiling go from source
>>>>
>>>> On Mon, Oct 19, 2020 at 2:06 PM Gerrit Binnenmars
>>>>  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
>

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

[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


On Thu, Oct 22, 2020 at 5:40 PM Gerrit Binnenmars <
gerritbinnenm...@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 
>> 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 
>>> Datum: 20-10-20 04:25 (GMT+01:00)
>>> Aan: Gerrit Binnenmars 
>>> Cc: golang-nuts 
>>> Onderwerp: Re: [go-nuts] gccgo problem compiling go from source
>>>
>>> On Mon, Oct 19, 2020 at 2:06 PM Gerrit Binnenmars
>>>  wrote:
>>> >
>>> > I used crosstool-ng successfully to build a go compiler for ppc e500.
>>> > Unfortunatel

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

[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:

>
>
> 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  
> 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  
>> Datum: 20-10-20 04:25 (GMT+01:00) 
>> Aan: Gerrit Binnenmars  
>> Cc: golang-nuts  
>> Onderwerp: Re: [go-nuts] gccgo problem compiling go from source 
>>
>> On Mon, Oct 19, 2020 at 2:06 PM Gerrit Binnenmars
>>  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="

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

[Gerrit Binnenmars]

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

On Tue, Oct 20, 2020 at 9:21 PM Ian Lance Taylor  wrote:
>
> On Tue, Oct 20, 2020 at 8:17 AM Gerrit Binnenmars
>  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

-- 
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/CAAjmYBUQYuxJyX32TEDW-na%3D5vTbQ_1uyb09OY3jjL20%3DrY4oQ%40mail.gmail.com.

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

[Ian Lance Taylor]

On Tue, Oct 20, 2020 at 8:17 AM Gerrit Binnenmars
 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

-- 
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/CAOyqgcXr9umgBzg6Ka1y6VN3q43BEfAo5Xi%2BHsLxCP_2oHVkWA%40mail.gmail.com.

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

[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


On Tuesday, October 20, 2020 at 5:18:05 PM UTC+2 Gerrit Binnenmars wrote:

> 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?
>
> 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  
>> 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  
>>> Datum: 20-10-20 04:25 (GMT+01:00) 
>>> Aan: Gerrit Binnenmars  
>>> Cc: golang-nuts  
>>> Onderwerp: Re: [go-nuts] gccgo problem compiling go from source 
>>>
>>> On Mon, Oct 19, 2020 at 2:06 PM Gerrit Binnenmars
>>>  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 be

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

[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?

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  
> 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  
>> Datum: 20-10-20 04:25 (GMT+01:00) 
>> Aan: Gerrit Binnenmars  
>> Cc: golang-nuts  
>> Onderwerp: Re: [go-nuts] gccgo problem compiling go from source 
>>
>> On Mon, Oct 19, 2020 at 2:06 PM Gerrit Binnenmars
>>  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"
>> &g

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

[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

-- 
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/A70DB211-2CDF-479B-8434-93D92E7A0901%40gmail.com.

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

[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



On Tue, Oct 20, 2020 at 6:20 AM gerritbinnenmars 
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 
> Datum: 20-10-20 04:25 (GMT+01:00)
> Aan: Gerrit Binnenmars 
> Cc: golang-nuts 
> Onderwerp: Re: [go-nuts] gccgo problem compiling go from source
>
> On Mon, Oct 19, 2020 at 2:06 PM Gerrit Binnenmars
>  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"
&

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

[fgergo]

On 10/20/20, gerritbinnenmars  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 )

-- 
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/CA%2Bctqrqy6AZd-U1VMu_Bd1Gf6amNo%2BBq3tcz_sjqudTRWqQMRg%40mail.gmail.com.

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

[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/goGerrit
 Oorspronkelijk bericht Van: Ian Lance Taylor  
Datum: 20-10-20  04:25  (GMT+01:00) Aan: Gerrit Binnenmars 
 Cc: golang-nuts  
Onderwerp: Re: [go-nuts] gccgo problem compiling go from source On Mon, Oct 19, 
2020 at 2:06 PM Gerrit Binnenmars 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 gccgostandard library.  That doesn't work.  The gccgo 
standard library mustbe built as part of GCC, using the usual configure/make 
commands usedto 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+unsubscr...@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.

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

[Ian Lance Taylor]

On Mon, Oct 19, 2020 at 2:06 PM Gerrit Binnenmars
 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWDf5AAGRgsreZYK14y6bTa7swdn1HjjM4RDGWeb8tH8w%40mail.gmail.com.

[go-nuts] 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)  

-- 
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/10e6c037-e755-4e58-a4c8-7f5cd8fde2e7n%40googlegroups.com.