Trying to port Go to HPE NonStop x86 - Need some guidance

[Randall Becker]

Hi All,

I know the subject has been covered for other platforms, but this one (HPE NonStop TNS/X) has a few quirks.

1. The platform does not support gcc at all. Many have spent years trying unsuccessfully to port gcc.
2. The platform does support a solid and POSIX compliant implementation of c99 and C libraries.
   
3. There are windows-based c99 cross-compilers that work well for the platform.
4. There is also a windows-based linker for the platform.
   
5. Cross-compiled gcc code will not run on the platform.
6. The platform is x86-64 bit, but it runs big-endian.
7. Intermediate and executable object files are in ELF format, but with some variation of values in the header that the linker handles.

Is there a direction that I should take in looking at the port? Try native or cross-compiling?

I need GO because there is a really important package written in it that I want to have on the platform. It is too big to port to another language, but that might be my backup plan. Am I out of luck or is there hope for this?

Thanks,

Randall

[Ian Lance Taylor]

Go only requires a C compiler if you want to support cgo. If the
package that you care about is pure Go, then the C compiler and linker
shouldn't matter. You won't need them.

You'll have to start by cross-compiling from some other platform. The
Go tools are written in Go, so you need to bootstrap starting on some
other platform.

You'll need to change cmd/link to generate an ELF file that your
platform can run. You'll likely need to change the compiler and
assembler for the fact that your platform is big-endian. That might
be simple, or it might be hard, I'm not sure.

It's hard to answer general questions like "what direction should I
take," but we'll be happy to answer specific questions as best we can.

Good luck.

Ian

[Randall Becker]

On Monday, 11 May 2020 16:37:31 UTC-4, Ian Lance Taylor wrote:

Thanks Ian.

I have the go repository with release-branch.go1.4 checked out on a Windows/cygwin64 installation. Looking for the bootstrap.bash and not finding one in that branch. Assuming that my eventual target will be called nsx (rather the standard name for other open source projects), would this be amd64 as a starting point, or does that not matter? Not sure about the next step. make.bat to build for Windows first?

Regards,

Randall

[Ian Lance Taylor]

On Tue, May 12, 2020 at 1:11 PM Randall Becker <the.n...@gmail.com> wrote:
>
> I have the go repository with release-branch.go1.4 checked out on a Windows/cygwin64 installation. Looking for the bootstrap.bash and not finding one in that branch. Assuming that my eventual target will be called nsx (rather the standard name for other open source projects), would this be amd64 as a starting point, or does that not matter? Not sure about the next step. make.bat to build for Windows first?

The only reason to use go1.4 is to use it to build a newer version of
Go, ideally the current version. Once you've built the current
version, use that for everything else, and set your go1.4 build aside
unless and until you need to build Go from scratch again.

Yes, I assume that you would use amd64 as a starting point, since your
target is 64-bit x86 based.

Ian

[Randall Becker]

On Tuesday, 12 May 2020 16:55:54 UTC-4, Ian Lance Taylor wrote:

So if I get this, build go1.4 from source under Windows, and bootstrap.bash (but that does not exist in the branch), with the GOOS=nsx and GOARCH=amd64, then build within the created tree using the cross compilers. Then build the newest on the target platform using the go1.4 cross compiled version.

Still wondering what to use for bootstrap.bash, though.

A little confused,

Randall

[Ian Lance Taylor]

No, build Go1.4 from source on Windows. Use that to build Go 1.14.2
(say) on Windows, as described at
https://golang.org/doc/install-source.html. Then use Go 1.14.2 with
bootstrap.bash. Go 1.14.2 comes with bootstrap.bash.

Once you have Go 1.14.2, throw away Go1.4 and never use it again. The
only reason to use Go1.4 is to build a newer version of Go. Once
you've done that, use the newer version of Go for everything.

For that matter, you can just download Go 1.14.2 for Windows. Go 1.4
is there for people who want to bootstrap from source rather than rely
on downloaded binaries.

Ian

[Randall Becker]

On Tuesday, 12 May 2020 20:02:01 UTC-4, Ian Lance Taylor wrote:

I have Go 1.14.2 installed and working under Windows. Not sure the next step. Sorry, I was assuming a source build, so I'm a bit clueless.

[Bruno Albuquerque]

Now you create your branch or whatever of the Go code and start porting it to your platform. As a first step, you will probably want to add the new nsx GOOS. Then you use your go1.14.2 installation to compile it (with bootstarp.sh) setting GOOS=nsx for cross compiling. Something like this:

GOOS=nsx GOARCH=ppc64 bootstrap.bash

That will not work at first. Now you have to make it work, which *IS* the porting process.

Eventually you will be able to compile everything and generate a go toolchain for your platform. At that point you will copy the generated files to the target platform and test it.

That will most likely fail in your first attempt. Then go back, fix what you think is broken and try again.

--
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/708b93b8-6aea-4339-85bb-06a69a32a481%40googlegroups.com.

[Randall Becker]

We've gotten nowhere on this despite trying. Installing GO on windows went fine, based on what Ian suggested, but specifying GOOS=nsx fails immediately as being unrecognized (rather obvious). The archictture is not a powerPC, so I'm not sure why I would start there - it is a big-endian x86.

On Wednesday, 13 May 2020 11:33:00 UTC-4, Bruno Albuquerque wrote:

Now you create your branch or whatever of the Go code and start porting it to your platform. As a first step, you will probably want to add the new nsx GOOS. Then you use your go1.14.2 installation to compile it (with bootstarp.sh) setting GOOS=nsx for cross compiling. Something like this:

GOOS=nsx GOARCH=ppc64 bootstrap.bash

That will not work at first. Now you have to make it work, which *IS* the porting process.

Eventually you will be able to compile everything and generate a go toolchain for your platform. At that point you will copy the generated files to the target platform and test it.

That will most likely fail in your first attempt. Then go back, fix what you think is broken and try again.

To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.

[Randall Becker]

Some progress. I've managed to build 1.14.4 using the Windows GO implementation. The trouble I was having was using cygwin64. After figuring that part out...

I checked out a new branch from release_go1.14 named nonstop_port

Then ran

GOARCH=amd64 GOOS=nsx bootstrap.bash

which failed because I am using cygwin64, but then ran make.bat from inside ../../go-nsx-amd64-bootstrap

That installed a go binary in go-nsx-amd64-bootstrap/bin

This still used the whatever compiler it chose to use, presumably gcc-generated code, but the executable will not run on the NonStop platform at all. The key here is that I need to use c99 for cross-compilation.

Where do I go next, please?

[Ian Lance Taylor]

On Fri, Jun 5, 2020 at 12:49 PM Randall Becker <the.n...@gmail.com> wrote:
>
> Some progress. I've managed to build 1.14.4 using the Windows GO implementation. The trouble I was having was using cygwin64. After figuring that part out...
>
> I checked out a new branch from release_go1.14 named nonstop_port
>
> Then ran
>
> GOARCH=amd64 GOOS=nsx bootstrap.bash
> which failed because I am using cygwin64, but then ran make.bat from inside ../../go-nsx-amd64-bootstrap
> That installed a go binary in go-nsx-amd64-bootstrap/bin
>
> This still used the whatever compiler it chose to use, presumably gcc-generated code, but the executable will not run on the NonStop platform at all. The key here is that I need to use c99 for cross-compilation.
>
> Where do I go next, please?

I'm sure how to answer that except to say that you need to add support
for nsx to the Go toolchain. The Go toolchain is written in Go, not
C, so the mention of c99 seems irrelevant. Your first step is to
build a Go toolchain that runs on your host system (not your nsx
system), which you've done. The second step is to add nsx support to
the toolchain. The third step is to run bootstrap.bash. The fact
that bootstrap.bash gives you a program that won't run on nsx suggests
that the second step is not complete.

Ian

> 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/736500a7-2dbd-4aba-8996-68b23c6532f5o%40googlegroups.com.

[Randall Becker]

That's actually what I figured. So where do I look to add nsx to the toolchain?

On Friday, 5 June 2020 17:03:11 UTC-4, Ian Lance Taylor wrote:

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/736500a7-2dbd-4aba-8996-68b23c6532f5o%40googlegroups.com.

[Ian Lance Taylor]

On Fri, Jun 5, 2020 at 3:46 PM Randall Becker <the.n...@gmail.com> wrote:
>
> That's actually what I figured. So where do I look to add nsx to the toolchain?

You'll have to fix the linker to generate whatever nsx expects.
You'll have to add code to support nsx in the runtime and syscall
packages. Pick which supported OS is most like nsx; let's say it's
linux. Look for *_linux.go and *_linux.s files; you'll need nsx
versions of those files. Look for +build lines in files that say
linux; you'll need to add nsx, or write a separate file that works on
nsx.

It's a lot of work.

Ian

> 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/2b6e78c3-a733-4162-801d-d50623018893o%40googlegroups.com.

[Gé Weijers]

I thought HPE Nonstop uses the Itanium processor (X64, not X86-64, it's completely unrelated to the common desktop CPU). You'd need to create a new code generator for that platform, and given that it's a VLIW processor that would be a major research project. Endianness is the least of your problems here, code generation for this type of processor is notoriously hard, so it does not surprise me that GCC is not available.

Gé

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXQyOMOq7dHT0JkwcJg6DHB3j-J8tGXOe84kowcy0H4PA%40mail.gmail.com.

--

Gé

[Randall Becker]

There are two variants - TNS/E, which uses Itanium, and TNS/X, which is x86-64. I'm going for the TNS/X variant because it is the future of the platform.

On Friday, 5 June 2020 22:09:09 UTC-4, Gé Weijers wrote:

I thought HPE Nonstop uses the Itanium processor (X64, not X86-64, it's completely unrelated to the common desktop CPU). You'd need to create a new code generator for that platform, and given that it's a VLIW processor that would be a major research project. Endianness is the least of your problems here, code generation for this type of processor is notoriously hard, so it does not surprise me that GCC is not available.

Gé

On Fri, Jun 5, 2020 at 4:02 PM Ian Lance Taylor <ia...@golang.org> wrote:

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/2b6e78c3-a733-4162-801d-d50623018893o%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 golan...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXQyOMOq7dHT0JkwcJg6DHB3j-J8tGXOe84kowcy0H4PA%40mail.gmail.com.

--

Gé

[Randall Becker]

Thanks. Where do fix the linker. I found the files to modify - so will basically copy the *_linux.go, *_linux.s in both runtime and syscalls to *_nsx.go and *_nsx.s, replacing +build lines with nsx instead of linux, I assume. Currently looking for an assembler cross-compiler for the platform (I may have to write one, something I'm much more comfortable with than the GO port) - I can wrap asm in C code, but I don't know how to get GO to recognize that.

On Friday, 5 June 2020 19:03:07 UTC-4, Ian Lance Taylor wrote:

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/2b6e78c3-a733-4162-801d-d50623018893o%40googlegroups.com.

[Ian Lance Taylor]

On Sat, Jun 6, 2020 at 8:57 AM Randall Becker <the.n...@gmail.com> wrote:
>
> Thanks. Where do fix the linker. I found the files to modify - so will basically copy the *_linux.go, *_linux.s in both runtime and syscalls to *_nsx.go and *_nsx.s, replacing +build lines with nsx instead of linux, I assume. Currently looking for an assembler cross-compiler for the platform (I may have to write one, something I'm much more comfortable with than the GO port) - I can wrap asm in C code, but I don't know how to get GO to recognize that.

Go uses its own assembler, in cmd/asm.

> 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/8c4b6dbd-f1af-4df4-a413-88e41d1b558co%40googlegroups.com.

[Shiva]

Trying to pick this up where it was left, we have the list of files *_linux.go, *_linux.s but not all of them have the build statements, do we create new nsx files only for those which have build statements in them or for all of those files? 

[Ian Lance Taylor]

On Tue, Mar 23, 2021 at 9:41 AM Shiva <emailshiva...@gmail.com> wrote:
>
> Trying to pick this up where it was left, we have the list of files *_linux.go, *_linux.s but not all of them have the build statements, do we create new nsx files only for those which have build statements in them or for all of those files?

For all of them. And add build tags to all of them. The use of build
tags in *_linux files is not consistent because the go tool has always
recognized *_linux file names specially.

Ian

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d12e5a2a-28f1-4f1f-9655-040fb0023878n%40googlegroups.com.

[Shiva]

Thank you for that, Ian. 

Just to confirm, I see the following - 

*_linux.c, 

*_linux.h,

*_linux.go,

*_linux.s,

*_linux.pl 

They are in different directories - crypto, internal\syscall, net, os, runtime, sync\atomic and syscall under the src directory. But you had earlier mentioned only runtime and syscall packages so do I have to add the rest too?

After this I suppose I run bootstrap.bash which should create a go package that I should try and run on the Nonstop. 

[Ian Lance Taylor]

On Wed, Mar 24, 2021 at 11:18 AM Shiva <emailshiva...@gmail.com> wrote:
>
> Thank you for that, Ian.
>
> Just to confirm, I see the following -
>
> *_linux.c,
> *_linux.h,
> *_linux.go,
> *_linux.s,
> *_linux.pl
>
> They are in different directories - crypto, internal\syscall, net, os, runtime, sync\atomic and syscall under the src directory. But you had earlier mentioned only runtime and syscall packages so do I have to add the rest too?
>
> After this I suppose I run bootstrap.bash which should create a go package that I should try and run on the Nonstop.

In the long run you will most likely have to handle all of those one
way or another, yes. Except probably for mksysnum_linux.pl.

Ian

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c1277ef8-b1d4-42bc-9692-c9ef2a226723n%40googlegroups.com.

[Shiva]

Thanks, Ian. Another step closer. Should the build statement just say: 

+build nsx 

Or should it be subject to any other rule, because I see a lot of different build statements in each of those directories and they vary.

[Ian Lance Taylor]

On Wed, Apr 7, 2021 at 4:47 AM Shiva <emailshiva...@gmail.com> wrote:
>
> Thanks, Ian. Another step closer. Should the build statement just say:
>
> +build nsx
>
> Or should it be subject to any other rule, because I see a lot of different build statements in each of those directories and they vary.

As a general guideline, follow the pattern of the existing files.

If there is a case that is unclear, let us know.

Ian

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/49d8cb7a-3a71-4ff5-a030-2f042de4137cn%40googlegroups.com.

[Shiva]

Thanks, Ian. I did as you suggested. 

One file specifically, types_linux.go which I duped into types_nsx.go has a build statement that goes like this '+build ignore'. Github discussions around this suggest to me that I don't have to build this? But happy to be corrected. 

Also, can I build the bootstrap on windows or can I only do it in a POSIX environment - I don't see bootstrap.bat and running bootstrap.bash with GOOS=nsx and GOARCH=amd64 simply returns back the prompt?

[Ian Lance Taylor]

On Wed, Apr 14, 2021 at 8:25 AM Shiva <emailshiva...@gmail.com> wrote:
>
> One file specifically, types_linux.go which I duped into types_nsx.go has a build statement that goes like this '+build ignore'. Github discussions around this suggest to me that I don't have to build this? But happy to be corrected.

The "+build ignore" line means that the file will not be built as part
of an ordinary "go build" or "go install". For a file like
syscall/types_linux.go, that is because the file originally served as
input to cgo -godefs as part of generating the various
ztypes_linux_GOARCH.go files.

> Also, can I build the bootstrap on windows or can I only do it in a POSIX environment - I don't see bootstrap.bat and running bootstrap.bash with GOOS=nsx and GOARCH=amd64 simply returns back the prompt?

You should be able to build a bootstrap on Windows but you'll have to
either replicate bootstrap.bash in a Windows style, or you'll have to
use something like cygwin to run the bootstrap.bash shell script.
There aren't that many real commands in bootstrap.bash so I think that
creating a minimal bootstrap.bat would be fairly simple.

Ian

[Shiva]

Since I haven't generated the various ztypes_nsx_GOARCH.go files, I think I need to use +build nsx and not ignore the build for types_nsx.go. 

I found a way to run bootstrap.bat on windows but I was told that I had to run make.bat instead, so I did. I had to add "nsx" to the array 'okgoos' in cmd\dist\build.c to be able to run make.bat so I did that too. And the output from make.bat had a lot of the same warning 'this statement may fall through [-Wimplicit-fallthrough=]' and I ignored them. And I had to update sym.c (liblink)'s headers array with an entry for nsx which made me realise that the following files will need to have 'switch cases' for Hnsx on a bunch of other asm*/obj files under cmd\*l and liblink. So I did them too. 

 I know that I also have to update cmd\ld\elf.c where I see three references required for Hnsx - one at elfinit and the other two under asmbelf function - one while setting interpreter and the other for setting elf protected headers (?). But I'm uncertain about the changes required in that file especially the one setting the interpreter because that requires pointing to the dynamic linker loader (different ones for OABI and EABI) in asm.c under cmd\*l directories? Can you please advise?

[Ian Lance Taylor]

On Fri, Apr 16, 2021 at 2:28 AM Shiva <emailshiva...@gmail.com> wrote:
>
> Since I haven't generated the various ztypes_nsx_GOARCH.go files, I think I need to use +build nsx and not ignore the build for types_nsx.go.
>
> I found a way to run bootstrap.bat on windows but I was told that I had to run make.bat instead, so I did. I had to add "nsx" to the array 'okgoos' in cmd\dist\build.c to be able to run make.bat so I did that too. And the output from make.bat had a lot of the same warning 'this statement may fall through [-Wimplicit-fallthrough=]' and I ignored them. And I had to update sym.c (liblink)'s headers array with an entry for nsx which made me realise that the following files will need to have 'switch cases' for Hnsx on a bunch of other asm*/obj files under cmd\*l and liblink. So I did them too.
>
> I know that I also have to update cmd\ld\elf.c where I see three references required for Hnsx - one at elfinit and the other two under asmbelf function - one while setting interpreter and the other for setting elf protected headers (?). But I'm uncertain about the changes required in that file especially the one setting the interpreter because that requires pointing to the dynamic linker loader (different ones for OABI and EABI) in asm.c under cmd\*l directories? Can you please advise?

I think you are on the wrong path here. The idea of using
bootstrap.bash is that you should not have to edit any of the Go 1.4 C
code at all. The idea is that you run bootstrap.bash on a system that
already has a working Go compiler installed. That working Go compiler
is then used as a cross-compiler to build a toolchain that will run on
nsx. That requires editing the Go tip code to support nsx. It does
not require editing any of the Go 1.4 code, and should not require
editing any C code at all.

Ian

> On Wednesday, April 14, 2021 at 8:25:55 PM UTC+1 Ian Lance Taylor wrote:
>>
>> On Wed, Apr 14, 2021 at 8:25 AM Shiva <emailshiva...@gmail.com> wrote:
>> >
>> > One file specifically, types_linux.go which I duped into types_nsx.go has a build statement that goes like this '+build ignore'. Github discussions around this suggest to me that I don't have to build this? But happy to be corrected.
>>
>> The "+build ignore" line means that the file will not be built as part
>> of an ordinary "go build" or "go install". For a file like
>> syscall/types_linux.go, that is because the file originally served as
>> input to cgo -godefs as part of generating the various
>> ztypes_linux_GOARCH.go files.
>>
>> > Also, can I build the bootstrap on windows or can I only do it in a POSIX environment - I don't see bootstrap.bat and running bootstrap.bash with GOOS=nsx and GOARCH=amd64 simply returns back the prompt?
>>
>> You should be able to build a bootstrap on Windows but you'll have to
>> either replicate bootstrap.bash in a Windows style, or you'll have to
>> use something like cygwin to run the bootstrap.bash shell script.
>> There aren't that many real commands in bootstrap.bash so I think that
>> creating a minimal bootstrap.bat would be fairly simple.
>>
>> 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/420ce2be-b241-435f-89f9-b5f7c121bb9an%40googlegroups.com.

[Shiva]

Ian,

I'm a bit confused now. Let me explain what I have been doing. 

1. Installed go on windows (go version go1.4-bootstrap-20170531 windows/amd64)

2. Duped linux files to nsx and added build statements

At this point, I am not supposed to run bootstrap.bash but run make.bat because my installation is on windows. And when I ran make.bat, it failed with the following error 'unknown $GOOS nsx', and the error was from cmd\dist\build.c because it looks for known values in the okgoos array. And there is no way for me to get past that if I use nsx, so I basically assumed that I had to 'add support' for a new target OS. It was the same case with sym.c. The only way I can make it work without updating these files would be to use goos=linux, I assume. 

My goal has always been to get a cross-compiled version of go1.4 so that I can move that to nsx and then compile the latest Go version on NSX. Please let me know if I'm not on the right direction. 

Shiva

[Ian Lance Taylor]

On Tue, Apr 20, 2021 at 1:39 AM Shiva <emailshiva...@gmail.com> wrote:
>
> I'm a bit confused now. Let me explain what I have been doing.
> 1. Installed go on windows (go version go1.4-bootstrap-20170531 windows/amd64)
> 2. Duped linux files to nsx and added build statements
> At this point, I am not supposed to run bootstrap.bash but run make.bat because my installation is on windows. And when I ran make.bat, it failed with the following error 'unknown $GOOS nsx', and the error was from cmd\dist\build.c because it looks for known values in the okgoos array. And there is no way for me to get past that if I use nsx, so I basically assumed that I had to 'add support' for a new target OS. It was the same case with sym.c. The only way I can make it work without updating these files would be to use goos=linux, I assume.
>
> My goal has always been to get a cross-compiled version of go1.4 so that I can move that to nsx and then compile the latest Go version on NSX. Please let me know if I'm not on the right direction.

Sorry, but I don't think you're on the right direction.

There is no reason to ever port Go 1.4 to nsx. The only reason we
talk about Go 1.4 at all is because it can be built without a
previously existing Go compiler. But you have a previously existing
Go compiler: Go 1.16 (or any other release) on Windows. Your goal
should be to port Go tip to nsx, not Go 1.4. Once you've ported Go
tip to support nsx, then you can build it, on Windows, using Go 1.16
and bootstrap.bash. That will give you a Go toolchain that will run
on nsx.

Porting Go 1.4 to nsx will be a lot of work that you will have to
completely redo in order to port Go tip. What you want in the end is
Go tip, not Go 1.4. So don't bother with Go 1.4 at all.

Ian

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3e8a31b9-f349-4984-8538-df7533fccb36n%40googlegroups.com.

[Shiva]

Thank you for clearing that up, Ian. I'll set this go1.4 installation aside and install Go 1.16 on windows then. But I am still a bit unclear on what you mean by 'porting Go tip to support nsx' - Can you expand on what you mean by Go tip? 

[Ian Lance Taylor]

On Wed, Apr 21, 2021 at 7:38 AM Shiva <emailshiva...@gmail.com> wrote:
>
> Thank you for clearing that up, Ian. I'll set this go1.4 installation aside and install Go 1.16 on windows then. But I am still a bit unclear on what you mean by 'porting Go tip to support nsx' - Can you expand on what you mean by Go tip?

I mean the code that you get when you run "git clone
https://go.googlesource.com". The code to which we commit changes.

Ian

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/4def7bf3-5e6d-4acf-98be-6860587234e3n%40googlegroups.com.

[Shiva]

So I've now done the following steps as you suggested after removing all the previous traces of Go from my machine to start from the scratch. 

1. Install go1.4 

2. Set GOROOT_BOOTSTRAP to go1.4

3. git clone go1.16

4. Run make.bat to 'make' Go on windows just to confirm that it does build fine (which it clearly does)

Now, I suppose I have to 'port' the current go1.16 src folder by creating 'nsx' files similar to 'linux'? I'm now working on them and hopefully will be able to break some ground. 

But I also have a question - I think the reason we chose to port go 1.4 instead of the latest source is because the latest source requires a pre-existing go compiler and Nonstop (our target) machine didn't have one. I suppose your earlier response suggests that as long as the intermediate system has a pre-existing go compiler that can be used, it doesn't matter if the target environment doesn't have a Go compiler - we can still bootstrap the latest version of the source. I just wanted to confirm this as I continued. 

Thank you for all the assistance, much appreciated. 

[Ian Lance Taylor]

On Wed, May 5, 2021 at 1:00 PM Shiva <emailshiva...@gmail.com> wrote:
>
> So I've now done the following steps as you suggested after removing all the previous traces of Go from my machine to start from the scratch.
>
> 1. Install go1.4
> 2. Set GOROOT_BOOTSTRAP to go1.4
> 3. git clone go1.16
> 4. Run make.bat to 'make' Go on windows just to confirm that it does build fine (which it clearly does)
>
> Now, I suppose I have to 'port' the current go1.16 src folder by creating 'nsx' files similar to 'linux'? I'm now working on them and hopefully will be able to break some ground.

Yes.

> But I also have a question - I think the reason we chose to port go 1.4 instead of the latest source is because the latest source requires a pre-existing go compiler and Nonstop (our target) machine didn't have one. I suppose your earlier response suggests that as long as the intermediate system has a pre-existing go compiler that can be used, it doesn't matter if the target environment doesn't have a Go compiler - we can still bootstrap the latest version of the source. I just wanted to confirm this as I continued.

Yes. That is what bootstrap.bash is for. See the description in the
comment near the start of bootstrap.bash.

Ian

[Shiva]

Thank you, that helps. 

Now, as I continue to work on 'porting', I have a question. The go compiler that will be used for creating this 'bootstrap' version of go1.16 - does this come from the go1.16 windows binary or the go1.4 windows binary? I ask because I have 'produced' both of them on different directories (as I should) and wanted to make sure I set the right 'GOROOT'/'GOPATH'/'GOBIN' variables and/or PATH to be able to produce the bootstrap version. 

[Shiva]

To give you a bit of a background - The question above was because I had set the go compiler as go1.4 and Visual Studio code complained that 'gopls requires at least go1.12.0' while I was in the process of 'porting'. 

[Ian Lance Taylor]

On Thu, May 6, 2021 at 6:16 AM Shiva <emailshiva...@gmail.com> wrote:
>
> Thank you, that helps.
>
> Now, as I continue to work on 'porting', I have a question. The go compiler that will be used for creating this 'bootstrap' version of go1.16 - does this come from the go1.16 windows binary or the go1.4 windows binary? I ask because I have 'produced' both of them on different directories (as I should) and wanted to make sure I set the right 'GOROOT'/'GOPATH'/'GOBIN' variables and/or PATH to be able to produce the bootstrap version.

The Go compiler used to create the bootstrap compiler will be the Go
1.16 Windows binary.

Ian

> On Wednesday, May 5, 2021 at 10:08:20 PM UTC+1 Ian Lance Taylor wrote:
>>
>> On Wed, May 5, 2021 at 1:00 PM Shiva <emailshiva...@gmail.com> wrote:
>> >
>> > So I've now done the following steps as you suggested after removing all the previous traces of Go from my machine to start from the scratch.
>> >
>> > 1. Install go1.4
>> > 2. Set GOROOT_BOOTSTRAP to go1.4
>> > 3. git clone go1.16
>> > 4. Run make.bat to 'make' Go on windows just to confirm that it does build fine (which it clearly does)
>> >
>> > Now, I suppose I have to 'port' the current go1.16 src folder by creating 'nsx' files similar to 'linux'? I'm now working on them and hopefully will be able to break some ground.
>>
>> Yes.
>>
>> > But I also have a question - I think the reason we chose to port go 1.4 instead of the latest source is because the latest source requires a pre-existing go compiler and Nonstop (our target) machine didn't have one. I suppose your earlier response suggests that as long as the intermediate system has a pre-existing go compiler that can be used, it doesn't matter if the target environment doesn't have a Go compiler - we can still bootstrap the latest version of the source. I just wanted to confirm this as I continued.
>>
>> Yes. That is what bootstrap.bash is for. See the description in the
>> comment near the start of bootstrap.bash.
>>
>> 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/d1337a2d-46ee-430c-bd92-bd7f3168b28en%40googlegroups.com.

[the.n...@gmail.com]

This is about as far as I got on the last attempt. Hopefully we can figure out how to generate code that will start to run on NonStop at some point soon.

-Randall

[Shiva]

I have now duped all of the linux files and created nsx variants, I've also set the environment variables GOOS to nsx and GOARCH to amd64. When I tried to run make.bat (If you try to port and run bootstrap.sh on windows, you get an error message directing you to run make.bat instead on windows), it complained that I should not uncomment "+build" or "+go:build" statements, so I commented them again on the nsx files that it complained about. Now I get the below error which makes sense as it sees multiple delcarations - but I'm unsure how to go about fixing it. Can you please advice? 

C:\Users\Sh\Documents\GitHub\goroot\src>make.bat

Building Go cmd/dist using C:\Users\Sh\Documents\GitHub\goroot

warning: GOPATH set to GOROOT (C:\Users\Sh\Documents\GitHub\goroot) has no effect

# runtime

runtime\defs_windows.go:10:2: _PROT_NONE redeclared in this block

        C:\Users\Sh\Documents\GitHub\goroot\src\runtime\defs_nsx_amd64.go:12:16: previous declaration

runtime\defs_windows.go:11:2: _PROT_READ redeclared in this block

        C:\Users\Sh\Documents\GitHub\goroot\src\runtime\defs_nsx_amd64.go:13:16: previous declaration

runtime\defs_windows.go:12:2: _PROT_WRITE redeclared in this block

        C:\Users\Sh\Documents\GitHub\goroot\src\runtime\defs_nsx_amd64.go:14:16: previous declaration

runtime\defs_windows.go:13:2: _PROT_EXEC redeclared in this block

        C:\Users\Sh\Documents\GitHub\goroot\src\runtime\defs_nsx_amd64.go:15:16: previous declaration

runtime\defs_windows.go:15:2: _MAP_ANON redeclared in this block

        C:\Users\Sh\Documents\GitHub\goroot\src\runtime\defs_nsx_amd64.go:17:17: previous declaration

runtime\defs_windows.go:16:2: _MAP_PRIVATE redeclared in this block

        C:\Users\Sh\Documents\GitHub\goroot\src\runtime\defs_nsx_amd64.go:18:17: previous declaration

runtime\defs_windows.go:21:2: _SIGINT redeclared in this block

        C:\Users\Sh\Documents\GitHub\goroot\src\runtime\defs_nsx_amd64.go:32:15: previous declaration

runtime\mem_windows.go:27:6: sysAlloc redeclared in this block

        C:\Users\Sh\Documents\GitHub\goroot\src\runtime\mem_nsx.go:20:47: previous declaration

runtime\mem_windows.go:32:6: sysUnused redeclared in this block

        C:\Users\Sh\Documents\GitHub\goroot\src\runtime\mem_nsx.go:39:36: previous declaration

runtime\mem_windows.go:62:6: sysUsed redeclared in this block

        C:\Users\Sh\Documents\GitHub\goroot\src\runtime\mem_nsx.go:119:34: previous declaration

runtime\mem_windows.go:62:6: too many errors

C:\Users\Sh\Documents\GitHub\goroot\src>

[Ian Lance Taylor]

On Wed, Jun 9, 2021 at 6:16 AM Shiva <emailshiva...@gmail.com> wrote:
>
> I have now duped all of the linux files and created nsx variants, I've also set the environment variables GOOS to nsx and GOARCH to amd64. When I tried to run make.bat (If you try to port and run bootstrap.sh on windows, you get an error message directing you to run make.bat instead on windows), it complained that I should not uncomment "+build" or "+go:build" statements, so I commented them again on the nsx files that it complained about. Now I get the below error which makes sense as it sees multiple delcarations - but I'm unsure how to go about fixing it. Can you please advice?
>
> C:\Users\Sh\Documents\GitHub\goroot\src>make.bat
> Building Go cmd/dist using C:\Users\Sh\Documents\GitHub\goroot
> warning: GOPATH set to GOROOT (C:\Users\Sh\Documents\GitHub\goroot) has no effect
> # runtime
> runtime\defs_windows.go:10:2: _PROT_NONE redeclared in this block
> C:\Users\Sh\Documents\GitHub\goroot\src\runtime\defs_nsx_amd64.go:12:16: previous declaration

You need to

1) Teach your toolchain about the nsx build tag by adding it to
goosList in go/build/syslist.go and okgoos in cmd/dist/build.go and
KnownOS in cmd/go/internal/imports/build.go.
2) Add +build and go:build lines to your new files with an nsx build
tag, so that older toolchains don't get confused (for example see
runtime/os_aix.go that both has aix in the file name and also has
+build/go:build lines).

Ian