On Wed, Jun 9, 2021 at 6:16 AM Shiva 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 mes
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),
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
On Thursday, May 6, 2021 at 10:35:27 p.m. UTC-4 Ian Lance Taylor wrote:
> On Thu, May 6, 2021 at 6:16 AM Shiva wrote:
> >
> > Thank
On Thu, May 6, 2021 at 6:16 AM Shiva 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
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'.
On Thursday, May 6, 2021 at 2:16:24 PM UTC+1 Shiva wrote:
> Thank you, that h
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 diff
On Wed, May 5, 2021 at 1:00 PM Shiva 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'
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 (w
On Wed, Apr 21, 2021 at 7:38 AM Shiva 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?
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?
On Tuesday, April 20, 2021 at 9:14:13 PM UTC+1 Ian Lanc
On Tue, Apr 20, 2021 at 1:39 AM Shiva 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 bootst
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 installati
On Fri, Apr 16, 2021 at 2:28 AM Shiva 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,
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
c
On Wed, Apr 14, 2021 at 8:25 AM Shiva 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 "
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
On Wed, Apr 7, 2021 at 4:47 AM Shiva 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 guidel
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.
On Wednesday, March 24, 2021 at 6:44:00 PM UTC Ian Lance Taylor wrote:
>
On Wed, Mar 24, 2021 at 11:18 AM Shiva 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 u
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 runtim
On Tue, Mar 23, 2021 at 9:41 AM Shiva 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
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?
On Sunday, June 7, 2020 at 2:38:09 AM UTC+1 Ian Lanc
On Sat, Jun 6, 2020 at 8:57 AM Randall Becker 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. Curren
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
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
> comple
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
On Fri, Jun 5, 2020 at 3:46 PM Randall Becker 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 suppo
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:
>
> On Fri, Jun 5, 2020 at 12:49 PM Randall Becker > wrote:
> >
> > Some progress. I've managed to build 1.14.4 using the Windows GO
> implementation.
On Fri, Jun 5, 2020 at 12:49 PM Randall Becker 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
>
> Th
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 a
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
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=ns
On Tuesday, 12 May 2020 20:02:01 UTC-4, Ian Lance Taylor wrote:
>
> On Tue, May 12, 2020 at 2:17 PM Randall Becker > wrote:
> >
> > On Tuesday, 12 May 2020 16:55:54 UTC-4, Ian Lance Taylor wrote:
> >>
> >> On Tue, May 12, 2020 at 1:11 PM Randall Becker
> wrote:
> >> >
> >> > I have the g
On Tue, May 12, 2020 at 2:17 PM Randall Becker wrote:
>
> On Tuesday, 12 May 2020 16:55:54 UTC-4, Ian Lance Taylor wrote:
>>
>> On Tue, May 12, 2020 at 1:11 PM Randall Becker wrote:
>> >
>> > I have the go repository with release-branch.go1.4 checked out on a
>> > Windows/cygwin64 installation.
On Tuesday, 12 May 2020 16:55:54 UTC-4, Ian Lance Taylor wrote:
>
> On Tue, May 12, 2020 at 1:11 PM Randall Becker > 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
On Tue, May 12, 2020 at 1:11 PM Randall Becker 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 s
On Monday, 11 May 2020 16:37:31 UTC-4, Ian Lance Taylor wrote:
> On Mon, May 11, 2020 at 8:45 AM Randall Becker > wrote:
> >
> > I know the subject has been covered for other platforms, but this one
> (HPE NonStop TNS/X) has a few quirks.
> >
> > The platform does not support gcc at all. Ma
On Mon, May 11, 2020 at 8:45 AM Randall Becker wrote:
>
> I know the subject has been covered for other platforms, but this one (HPE
> NonStop TNS/X) has a few quirks.
>
> The platform does not support gcc at all. Many have spent years trying
> unsuccessfully to port gcc.
> The platform does sup
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 implementa
39 matches
Mail list logo
