Re: [9fans] Go on Plan 9?

[Skip Tavakkolian]

I use GOROOT=$home/go to keep up with tip.  after bootstrapping, rebuild
the standard packages and commands:

% GOBIN=$home/bin/386 $home/go/bin/go install -a std cmd

and

% GOARCH=arm go install -a std cmd

then in my profile:

% test -d $home/go/bin/plan9_^$cputype && bind
-a $home/go/bin/plan9_^$cputype /bin  || bind -a $home/go/bin /bin

unfortunately because the treatment of GOBIN is not symmetrical when
$GOARCH == $cputype  vs  $GOARCH != $cputype,  we can't do:

% for (GOARCH in (386 arm)) {
echo GOBIN=$home/bin/$GOARCH $home/go/bin/go install -a std cmd
}


-Skip

On Wed, Apr 13, 2016 at 12:34 AM,  wrote:
>
>
> Skip, where in the FS hierarchy do you install the go distribution?
> Also, which additional go packages are in general use on Plan 9
> platforms and where do they normally get installed?
>
> Lucio.
>
>
>

Re: [9fans] Go on Plan 9?

[Richard Miller]

> Still, how much swap are we talking about?

On a 1GB system, the default test suite swaps in only a handful of places.
It's possible to limit the concurrency enough to cut out swapping, but
then it takes longer because there's less opportunity to overlap cpu-bound
tests with file I/O and paging-in of commands.

Re: [9fans] Go on Plan 9?

[lucio]

> If you want to get to the satisfying ALL TESTS PASSED message at the end
> of the go install+test process, you will need a swap file, even on a
> 1GB raspberry pi.  Trust me.

Sounds like a challenge, but I never quite wanted to know whether Plan
9 swap is or isn't broken.  Still, how much swap are we talking about?
It can't be nice on a device like the rPi.

Lucio.

Re: [9fans] Go on Plan 9?

[Richard Miller]

> That's insane. Really.

The designer(s) of the test suite had bigger systems in mind,
so there's lots of stuff running concurrently.

Re: [9fans] Go on Plan 9?

[Charles Forsyth]

On 13 April 2016 at 15:42, Charles Forsyth 
wrote:

> On 13 April 2016 at 15:39, Richard Miller <9f...@hamnavoe.com> wrote:
>
>> If you want to get to the satisfying ALL TESTS PASSED message at the end
>> of the go install+test process, you will need a swap file,
>>
>
> That's insane. Really.


More helpfully, it would be useful to find the relevant tests and make them
conditional on configuration.
I'm sure it makes sense to test big memory systems, but it's somewhat
limiting to insist on an Internet of Tanks
instead of Things.

Re: [9fans] Go on Plan 9?

[Charles Forsyth]

On 13 April 2016 at 15:39, Richard Miller <9f...@hamnavoe.com> wrote:

> If you want to get to the satisfying ALL TESTS PASSED message at the end
> of the go install+test process, you will need a swap file,
>

That's insane. Really.

Re: [9fans] Go on Plan 9?

[Richard Miller]

> It won't need a swap file unless the program forces all that to be
> allocated, which it shouldn't,

If you want to get to the satisfying ALL TESTS PASSED message at the end
of the go install+test process, you will need a swap file, even on a
1GB raspberry pi.  Trust me.

Re: [9fans] Go on Plan 9?

[Kenny Lasse Hoff Levinsen]

I tried that at some point. Got pi2 booting with one core, crashed with 
multiple, but then again, I'm new to having to be that intimate with assembly 
and kernel mode.

I'd suggest trying from scratch to port things, but there are a few 9front 
differences that make it much more than just a diff.

Best regards,
Kenny Levinsen

> On 13. apr. 2016, at 16.00, Chris McGee  wrote:
> 
> Ah, that makes sense. It’s virtual memory and not the physical memory.
> 
> Do you think that your changes to the bcm will make it to 9front? If not, any 
> chance I could have the diffs so that I can try merging them in there myself?
> 
> Thanks,
> Chris

Re: [9fans] Go on Plan 9?

[Charles Forsyth]

On 13 April 2016 at 14:08, Chris McGee  wrote:

> I believe that my rpi only has the 512MB of RAM so I’ll add swap.


It should be enough to increase the available virtual space by changing
that #define.
It won't need a swap file unless the program forces all that to be
allocated, which it shouldn't,
and if it does, you still won't want to swap since it doesn't work well.

In fact, I've ripped the paging and swap crud out of my own systems. The
time for that was years ago,
and it certainly makes no sense at all on any small device. The code and
data get a lot simpler too.

Re: [9fans] Go on Plan 9?

[Chris McGee]

Ah, that makes sense. It’s virtual memory and not the physical memory.

Do you think that your changes to the bcm will make it to 9front? If not, any 
chance I could have the diffs so that I can try merging them in there myself?

Thanks,
Chris

Re: [9fans] Go on Plan 9?

[Richard Miller]

> I didn’t realize that Go was so virtual memory hungry. I wonder why stats 
> didn’t show me a large peak of memory consumption before the go compiler died?

stats -m shows physical memory usage.  Every go program starts by allocating
a huge block of virtual space for its garbage-collected allocation arena.
A lot of that will normally remain unused, so no corresponding physical ram
need be allocated.

> Are these changes going to make it into the official kernel source? Any 
> reason why everyone, even non Go users, wouldn’t want the changes?

Depends what you mean by "official".  The rpi specific changes are all in
/n/sources/contrib/miller/9/bcm, and I will be sending patches for the portable
changes soon.  This is only for reference - it has been some time since any
patches were being applied on /n/sources/plan9.

> I didn’t realize that Go programs were so heavy weight. What do embedded Go 
> users have to do to make things work on other platforms like Linux?

Depends what you mean by "embedded".  The VM allocation is probably less
significant for very small platforms than the size of the runtime library.

cpu% cat smallest.go
package main
func main() {
}
cpu% go build smallest.go
cpu% ls -l smallest
--rwxr-x--x M 3990 miller miller 614356 Apr 13 14:42 smallest
cpu% size smallest
466123t + 1792d + 87712b = 555627   smallest

Re: [9fans] Go on Plan 9?

[Chris McGee]

Thanks Richard for doing the go port to plan9/arm. I was going to start on that 
myself until I found out it was already done. :-)

I didn’t realize that Go was so virtual memory hungry. I wonder why stats 
didn’t show me a large peak of memory consumption before the go compiler died? 
Perhaps it allocates a huge chunk of virtual memory on startup.

I’ll check for that kernel change in my kernel source. If it’s not there I’ll 
recompile and give it a shot. Are these changes going to make it into the 
official kernel source? Any reason why everyone, even non Go users, wouldn’t 
want the changes?

I believe that my rpi only has the 512MB of RAM so I’ll add swap. I didn’t 
realize that Go programs were so heavy weight. What do embedded Go users have 
to do to make things work on other platforms like Linux?

Cheers,
Chris

> On Apr 13, 2016, at 5:10 AM, Richard Miller <9f...@hamnavoe.com> wrote:
> 
>> I tried a bootstrapped version on my RPi but it fails with a "fork/exec ... 
>> virtual memory allocation failed” error when I try to compile anything.
> 
> Go needs a lot of virtual memory - it won't even pass the installation test 
> suite
> if you give it less than a gigabyte.  That was the reason for the change to 
> the
> definition in /sys/src/9/bcm/mem.h mentioned earlier:
> 
> < #define USTKTOP 0x2000  /* user segment end +1 
> */
> ---
>> #define  USTKTOP 0x4000  /* user segment end +1 
>> */
> 
> Are you running a 9pi kernel built with this change?  There are newer kernel 
> binaries
> in /n/sources/contrib/miller/9pi* with this and other tweaks applied.  If you 
> are
> using an older pi with 512MB of ram, you'll need to activate swap(8).
> 
> The plan9_arm version of go is expected to be in the 1.7 release.  It is 
> already
> self hosting: if you look at the builder dashboard in http://build.golang.org
> which tracks updates being built and tested on all platforms, the "plan9 arm"
> column at the far right is a Raspberry Pi 3 managed by David du Colombier.
> It doesn't keep up with every update because a complete build and test suite
> run takes a bit over an hour.
> 
> 

Re: [9fans] Go on Plan 9?

[Richard Miller]

> I tried a bootstrapped version on my RPi but it fails with a "fork/exec ... 
> virtual memory allocation failed” error when I try to compile anything.

Go needs a lot of virtual memory - it won't even pass the installation test 
suite
if you give it less than a gigabyte.  That was the reason for the change to the
definition in /sys/src/9/bcm/mem.h mentioned earlier:

< #define   USTKTOP 0x2000  /* user segment end +1 
*/
---
> #define   USTKTOP 0x4000  /* user segment end +1 
> */

Are you running a 9pi kernel built with this change?  There are newer kernel 
binaries
in /n/sources/contrib/miller/9pi* with this and other tweaks applied.  If you 
are
using an older pi with 512MB of ram, you'll need to activate swap(8).

The plan9_arm version of go is expected to be in the 1.7 release.  It is already
self hosting: if you look at the builder dashboard in http://build.golang.org
which tracks updates being built and tested on all platforms, the "plan9 arm"
column at the far right is a Raspberry Pi 3 managed by David du Colombier.
It doesn't keep up with every update because a complete build and test suite
run takes a bit over an hour.

Re: [9fans] Go on Plan 9?

[Richard Miller]

> I tried a bootstrapped version on my RPi but it fails with a "fork/exec ... 
> virtual memory allocation failed” error when I try to compile anything.

Go needs a lot of virtual memory - it won't even pass the installation test 
suite
if you give it less than a gigabyte.  That was the reason for the change to the
definition in /sys/src/9/bcm/mem.h mentioned earlier:

< #define   USTKTOP 0x2000  /* user segment end +1 
*/
---
> #define   USTKTOP 0x4000  /* user segment end +1 
> */

Are you running a 9pi kernel built with this change?  There are newer kernel 
binaries
in /n/sources/contrib/miller/9pi* with this and other tweaks applied.  If you 
are
using an older pi with 512MB of ram, you'll need to activate swap(8).

The plan9_arm version of go is expected to be in the 1.7 release.  It is already
self hosting: if you look at the builder dashboard in http://build.golang.org
which tracks updates being built and tested on all platforms, the "plan9 arm"
column near the far right is a Raspberry Pi 3 managed by David du Colombier.
It doesn't keep up with every update because a complete build and test suite
run takes a bit over an hour.

Re: [9fans] Go on Plan 9?

[lucio]

> Skip, isn't the point here that being able to run go binaries
> in Plan 9 on an arm machine is news to most Plan 9 users?

Go seems a little outside the scope of a Plan 9 release and I think it
would take a greater interest by the community to bring it in.  I seem
to recall that Quanstro's 9atom does not implement syscall 53
(nanotime), as a probable example of where the thinking diverges.

It is certainly the case that Go has distinctive philosophy that
differs in place from Plan 9 and I see no reason not to treat the two
as distinct.

Expecting the Plan 9 community to focus on Go would be unreasonable,
in my opinion.  It does not mean that the shift can't take place, but
it should not be forced.

Skip, where in the FS hierarchy do you install the go distribution?
Also, which additional go packages are in general use on Plan 9
platforms and where do they normally get installed?

Lucio.

Re: [9fans] Go on Plan 9?

[lucio]

> I tried a bootstrapped version on my RPi but it fails with a
> "fork/exec ...  virtual memory allocation failed” error when I try to
> compile anything.  According to stats I have plenty of memory left
> when it runs.  I’m not sure what to make of it.  Any idea if the port
> is complete or if there are additional commits in progress?

I'm sure Richard will respond; I think this is a known problem and has
been addressed.  I seem to recall (not having an rPI of my own) that
the cause lies outside Go.

Lucio.

PS: In passing, I have Plan 9 running - in a limited sense - on
MIPS-64 on my Yeeloong notebook and I have also experimented with
linux/mips64 on the same platform (thank you Cherry for both!).

>From there, I think the next milestones ought to be plan9/mips64 and
exp/shiny.  That would be bliss.

Re: [9fans] Go on Plan 9?

[lucio]

> Next to try on Plan 9: build a linux/s390x binary and find a machine to run
> it on :)

I have certainly done that with linux/386 under Plan 9.  It works like
a charm, even if the compilation is a lot slower than doing it
natively on the target machine (which I could eventually install Go
on).

Lucio.

Re: [9fans] Go on Plan 9?

[Chris McGee]

I see now that there is plan9/arm in tip (1.7), but not 1.6.

I tried a bootstrapped version on my RPi but it fails with a "fork/exec ... 
virtual memory allocation failed” error when I try to compile anything. 
According to stats I have plenty of memory left when it runs. I’m not sure what 
to make of it. Any idea if the port is complete or if there are additional 
commits in progress?

For linux/s390x you can run it fairly easily (if slowly) in a Hercules emulator 
on Linux/Mac. I believe that there is at least one tutorial out there that I 
have successfully followed to get it working.

Chris

> On Apr 12, 2016, at 10:50 PM, Skip Tavakkolian  
> wrote:
> 
> I think Richards' CL's were submitted to main Go repo before Go 1.6 and are 
> now in 1.7 dev branch (tip). I believe I first saw the announcement on godev 
> list. as a Go user, it is a good way of keeping up with the fast-paced 
> development; e.g. IBM's linux/s390x port went in today!
> 
> I usually keep one environment in sync with the latest sources and try out 
> the new features that affect me the most, but I don't think there's anything 
> special about that.
> 
> Next to try on Plan 9: build a linux/s390x binary and find a machine to run 
> it on :)
> 
> 
> 
> On Tue, Apr 12, 2016 at 2:44 PM, > 
> wrote:
> Skip, isn't the point here that being able to run go binaries
> in Plan 9 on an arm machine is news to most Plan 9 users?
> 
> Perhaps even news to those who regularly use go on Plan 9.
> 
> sl
> 
> 

Re: [9fans] Go on Plan 9?

[Skip Tavakkolian]

I think Richards' CL's were submitted to main Go repo before Go 1.6 and are
now in 1.7 dev branch (tip). I believe I first saw the announcement on
godev list. as a Go user, it is a good way of keeping up with the
fast-paced development; e.g. IBM's linux/s390x port went in today!

I usually keep one environment in sync with the latest sources and try out
the new features that affect me the most, but I don't think there's
anything special about that.

Next to try on Plan 9: build a linux/s390x binary and find a machine to run
it on :)



On Tue, Apr 12, 2016 at 2:44 PM,  wrote:

> Skip, isn't the point here that being able to run go binaries
> in Plan 9 on an arm machine is news to most Plan 9 users?
>
> Perhaps even news to those who regularly use go on Plan 9.
>
> sl
>
>

Re: [9fans] Go on Plan 9?

[sl]

Skip, isn't the point here that being able to run go binaries
in Plan 9 on an arm machine is news to most Plan 9 users?

Perhaps even news to those who regularly use go on Plan 9.

sl

Re: [9fans] Go on Plan 9?

[Chris McGee]

Thanks,

I'll give it a shot.

I noticed that there are some assembly files in golang for plan9/386 and no 
equivalent for plan9/arm so I assumed that it wouldn't work with that 
combination.

Chris

> On Apr 12, 2016, at 5:26 PM, Skip Tavakkolian  
> wrote:
> 
> i've not built Go under plan9/arm.  however, in practice (in a real Plan 9 
> environment) this is not an issue. the way authentication and namespaces 
> (including file server) work in a Plan 9 envrionment, it is natural to use 
> the fastest cpu available to (cross) compile apps. typical sessions are like 
> this:
> 
> supermic% ls -l
> d-rwxrwxr-x M 5543 fst fst   0 Jul 21  2015 .hg
> --rw-rw-r-- M 5543 fst fst1071 Feb 10  2013 LICENSE
> --rw-rw-r-- M 5543 fst fst 206 Feb 10  2013 README
> --rw-rw-r-- M 5543 fst fst   12477 Feb 10  2013 admui.go
> --rw-rw-r-- M 5543 fst fst6332 Feb 10  2013 client.go
> --rw-rw-r-- M 5543 fst fst8623 Feb 10  2013 index.html
> --rw-rw-r-- M 5543 fst fst 450 Feb 10  2013 logger.go
> --rw-rw-r-- M 5543 fst fst1307 Feb 10  2013 main.go
> --rw-rw-r-- M 5543 fst fst4232 May 13  2013 server.go
> --rwxrwxr-x M 5543 fst fst 5977542 Apr 12 13:57 tcpmeter
> supermic% rm tcpmeter
> supermic% go build
> supermic% ls -ltr
> --rw-rw-r-- M 5543 fst fst6332 Feb 10  2013 client.go
> --rw-rw-r-- M 5543 fst fst 450 Feb 10  2013 logger.go
> --rw-rw-r-- M 5543 fst fst1071 Feb 10  2013 LICENSE
> --rw-rw-r-- M 5543 fst fst1307 Feb 10  2013 main.go
> --rw-rw-r-- M 5543 fst fst 206 Feb 10  2013 README
> --rw-rw-r-- M 5543 fst fst   12477 Feb 10  2013 admui.go
> --rw-rw-r-- M 5543 fst fst8623 Feb 10  2013 index.html
> --rw-rw-r-- M 5543 fst fst4232 May 13  2013 server.go
> d-rwxrwxr-x M 5543 fst fst   0 Jul 21  2015 .hg
> --rwxrwxr-x M 5543 fst fst 5855281 Apr 12 14:00 tcpmeter
> supermic% file tcpmeter
> tcpmeter: 386 plan 9 executable
> supermic% ./tcpmeter -?
> flag provided but not defined: -?
> 2016/04/12 14:00:31 usage: ./tcpmeter (-c|-s) [-r [host:]port] [-h 
> [host:]port] [-l logfile]
> supermic% GOARCH=arm go build
> supermic% file tcpmeter
> tcpmeter: arm plan 9 executable
> supermic% cpu -h rpi2
> rpi2% ./tcpmeter -?
> flag provided but not defined: -?
> 2016/04/12 14:04:35 usage: ./tcpmeter (-c|-s) [-r [host:]port] [-h 
> [host:]port] [-l logfile]
> rpi2% pwd
> /usr/fst/GoApps/src/tcpmeter
> rpi2% exit
> supermic% pwd
> /usr/fst/GoApps/src/tcpmeter
> supermic% 
> 
> Similar setup could be done under Linux/MacOSX with some work. I found this 
> article very helpful:
> https://medium.com/@rakyll/go-1-5-cross-compilation-488092ba44ec#.635w6yhi5
> 
> btw, building Go on rpi/linux, took some time.  i have not tried rpi3 yet 
> (waiting for 64bit plan9 or linux).  building Go on odroid-c2 (linux/arm64) 
> "feels" as speedy as on atom or i3.
> 
> 
>> On Tue, Apr 12, 2016 at 12:21 PM, Chris McGee  wrote:
>> Hi Skip,
>> 
>> Have you managed to get Go running on an RPi this way?
>> 
>> Cheers,
>> Chris
>> 
>> >
>> > If you run Plan 9 in a VM, emulator or a confined device (RPi), it will be 
>> > easier/faster to cross compile your app and copy it over. E.g. to compile 
>> > for 9Pi:
>> > $ GOOS=plan9 GOARCH=arm go build
>> >
>> >
> 

Re: [9fans] Go on Plan 9?

[Skip Tavakkolian]

i've not built Go under plan9/arm.  however, in practice (in a real Plan 9
environment) this is not an issue. the way authentication and namespaces
(including file server) work in a Plan 9 envrionment, it is natural to use
the fastest cpu available to (cross) compile apps. typical sessions are
like this:

supermic% ls -l
d-rwxrwxr-x M 5543 fst fst   0 Jul 21  2015 .hg
--rw-rw-r-- M 5543 fst fst1071 Feb 10  2013 LICENSE
--rw-rw-r-- M 5543 fst fst 206 Feb 10  2013 README
--rw-rw-r-- M 5543 fst fst   12477 Feb 10  2013 admui.go
--rw-rw-r-- M 5543 fst fst6332 Feb 10  2013 client.go
--rw-rw-r-- M 5543 fst fst8623 Feb 10  2013 index.html
--rw-rw-r-- M 5543 fst fst 450 Feb 10  2013 logger.go
--rw-rw-r-- M 5543 fst fst1307 Feb 10  2013 main.go
--rw-rw-r-- M 5543 fst fst4232 May 13  2013 server.go
--rwxrwxr-x M 5543 fst fst 5977542 Apr 12 13:57 tcpmeter
supermic% rm tcpmeter
supermic% go build
supermic% ls -ltr
--rw-rw-r-- M 5543 fst fst6332 Feb 10  2013 client.go
--rw-rw-r-- M 5543 fst fst 450 Feb 10  2013 logger.go
--rw-rw-r-- M 5543 fst fst1071 Feb 10  2013 LICENSE
--rw-rw-r-- M 5543 fst fst1307 Feb 10  2013 main.go
--rw-rw-r-- M 5543 fst fst 206 Feb 10  2013 README
--rw-rw-r-- M 5543 fst fst   12477 Feb 10  2013 admui.go
--rw-rw-r-- M 5543 fst fst8623 Feb 10  2013 index.html
--rw-rw-r-- M 5543 fst fst4232 May 13  2013 server.go
d-rwxrwxr-x M 5543 fst fst   0 Jul 21  2015 .hg
--rwxrwxr-x M 5543 fst fst 5855281 Apr 12 14:00 tcpmeter
supermic% file tcpmeter
tcpmeter: 386 plan 9 executable
supermic% ./tcpmeter -?
flag provided but not defined: -?
2016/04/12 14:00:31 usage: ./tcpmeter (-c|-s) [-r [host:]port] [-h
[host:]port] [-l logfile]
supermic% GOARCH=arm go build
supermic% file tcpmeter
tcpmeter: arm plan 9 executable
supermic% cpu -h rpi2
rpi2% ./tcpmeter -?
flag provided but not defined: -?
2016/04/12 14:04:35 usage: ./tcpmeter (-c|-s) [-r [host:]port] [-h
[host:]port] [-l logfile]
rpi2% pwd
/usr/fst/GoApps/src/tcpmeter
rpi2% exit
supermic% pwd
/usr/fst/GoApps/src/tcpmeter
supermic%

Similar setup could be done under Linux/MacOSX with some work. I found this
article very helpful:
https://medium.com/@rakyll/go-1-5-cross-compilation-488092ba44ec#.635w6yhi5

btw, building Go on rpi/linux, took some time.  i have not tried rpi3 yet
(waiting for 64bit plan9 or linux).  building Go on odroid-c2 (linux/arm64)
"feels" as speedy as on atom or i3.


On Tue, Apr 12, 2016 at 12:21 PM, Chris McGee  wrote:

> Hi Skip,
>
> Have you managed to get Go running on an RPi this way?
>
> Cheers,
> Chris
>
> >
> > If you run Plan 9 in a VM, emulator or a confined device (RPi), it will
> be easier/faster to cross compile your app and copy it over. E.g. to
> compile for 9Pi:
> > $ GOOS=plan9 GOARCH=arm go build
> >
> >
>
>
>

Re: [9fans] Go on Plan 9?

[Dave MacFarlane]

I've managed to get Go running on an RPi2 using a similar method, but:

1. You need to make sure you're using go-tip. <= 1.6 doesn't have Plan9/arm
support.
2. I had to apply this patch that Richard Miller sent me to my kernel:

term% diff /n/sources/contrib/miller/9/bcm/mem.h /sys/src/9/bcm/mem.h
55c55
< #define   USTKTOP 0x2000  /* user segment end
+1 */
---
> #define   USTKTOP 0x4000  /* user segment end
+1 */

(Then realized that the git client I was writing in Go wasn't ready enough
to use
as a daily driver for developing Go programs under Plan9, so I didn't go
much
further than that and compiling a few test programs..)

-- Dave

On Tue, Apr 12, 2016 at 3:21 PM, Chris McGee  wrote:

> Hi Skip,
>
> Have you managed to get Go running on an RPi this way?
>
> Cheers,
> Chris
>
> >
> > If you run Plan 9 in a VM, emulator or a confined device (RPi), it will
> be easier/faster to cross compile your app and copy it over. E.g. to
> compile for 9Pi:
> > $ GOOS=plan9 GOARCH=arm go build
> >
> >
>
>
>


-- 
- Dave

Re: [9fans] Go on Plan 9?

[Chris McGee]

Hi Skip,

Have you managed to get Go running on an RPi this way?

Cheers,
Chris

> 
> If you run Plan 9 in a VM, emulator or a confined device (RPi), it will be 
> easier/faster to cross compile your app and copy it over. E.g. to compile for 
> 9Pi:
> $ GOOS=plan9 GOARCH=arm go build
> 
> 

Re: [9fans] Go on Plan 9?

[Skip Tavakkolian]

Yes, this works and is the easier of the two methods.  Using a desktop OS
and starting no Go compilers:

1. download the Go 1.6 binaries for your desktop OS and install them; set
GOROOT_BOOTSTRAP to that directory (e.g. /usr/local/go)

2. copy the Go 1.6 sources (either the tar.gz or git clone of sources) to
your desktop OS; set GOROOT to that directory (e.g. $HOME/go)

3. build the bootstrap for Plan 9 (i.e. go-plan9-386-bootstrap.tbz) on your
desktop:
$ cd $GOROOT/src
$ GOOS=plan9 GOARCH=386 ./bootstrap.bash
   if all is well, this will produce ../../go-plan9-386-bootstrap.tbz

4. untar this in your Plan 9 environment and set GOROOT_BOOTSTRAP to that
directory; e.g. drawterm from your desktop OS to Plan 9:
% cd $home
% bunzip2 -c /mnt/term/path-to-go-plan9-386-bootstrap.tbz | tar -xv
% GOROOT_BOOTSTRAP=$home/go-plan9-386-bootstrap

5. copy Go 1.6 sources to your Plan 9 fs and set GOROOT to that directory;
e.g. drawterm from your desktop OS to Plan 9:
% mkdir $home/go
% dircp /mnt/term/path-of-GOROOT-on-desktop $home/go
% GOROOT=$home/go
% cd $GOROOT/src
% ./all.rc

If you run Plan 9 in a VM, emulator or a confined device (RPi), it will be
easier/faster to cross compile your app and copy it over. E.g. to compile
for 9Pi:
$ GOOS=plan9 GOARCH=arm go build

-Skip


On Mon, Apr 11, 2016 at 5:59 PM, Chris McGee  wrote:
>
>
> It may also be possible to cross compile a bootstrap of Go from
> Linux/Mac/Windows using the bootstrap.sh script after setting GOOS=plan9,
> GOARCH=386 and GO386=387. That bootstrap can be placed into plan9 and used
> as the GOROOT_BOOTSTRAP to compile a full Go installation on the plan9
> system.
>
>
>

Re: [9fans] Go on Plan 9?

[Chris McGee]

Hi All,

A while back there was a thread about getting newer versions of Go running on 
plan9. In particular there was a panic related to a floating point error.

In case anyone is interested I have managed to get the newest version of Go 
working on plan9/386 within virtualbox despite having a similar floating point 
error as was mentioned here before in that thread.

1) Download, extract and compile Go 1.4.3 from the source tarball
New versions of Go require older versions in order to compile through a 
bootstrapping process.
This is the last version that can be compiled without bootstrapping.
Modify the include/plan9/386/u.h and remove the line that has a typedef for 
intptr (in my 9front install this is already declared elsewhere).
Run the make.rc script in the src directory (don’t run all of the tests as many 
of them appear to fail)

2) Download, extract and compile Go 1.5.3
Set GOROOT_BOOTSTRAP to the go directory for 1.4.3 compiled above
Set GO386=387 (this is important as there appears to be a problem with sse2 
floating point with Go in my environment - plan9/386/virtualbox)
https://github.com/golang/go/issues/15234
Run the make.rc script (skip the tests for now)

3) Download, extract and compile Go 1.6
Set GOROOT_BOOTSTRAP to the 1.5.3 go directory
Run the all.rc script

Step 2 may not be necessary, but it worked for me this way.

It may also be possible to cross compile a bootstrap of Go from 
Linux/Mac/Windows using the bootstrap.sh script after setting GOOS=plan9, 
GOARCH=386 and GO386=387. That bootstrap can be placed into plan9 and used as 
the GOROOT_BOOTSTRAP to compile a full Go installation on the plan9 system.

I hope that this is useful information for others who are trying to get Go 
working on plan9.

Cheers,
Chris

Re: [9fans] Go on Plan 9?

[Charles Forsyth]

On 27 January 2016 at 01:40, Sean Caron  wrote:

> update process running:
>
> replica/pull -v /dist/replica/network
>

Beware that the introduction of the nsec system call can cause trouble if
replica updates commands before you're running the new kernel.

Re: [9fans] Go on Plan 9?

[David du Colombier]

> Yeah, thank goodness for snapshots :O Running replica/pull didn't turn out
> so good for my current running system. It looks like it might make the most
> sense to just archive my home directory and reload a fresh VM ...
>
> Where are they keeping the most current installation ISO these days? I'm
> just not sure of what's canonical now that the old bell-labs.com domain is
> offline.

You can download the latest Plan 9 CD image here:

https://9p.io/plan9/download/plan9.iso.bz2

-- 
David du Colombier

Re: [9fans] Go on Plan 9?

[lucio]

> Where are they keeping the most current installation ISO these days? I'm
> just not sure of what's canonical now that the old bell-labs.com domain is
> offline.

David is in charge of legacy Plan 9 outside of Bell Labs. His instructions were 
pretty explicit, but if you run into trouble I'll be happy to guide you. I 
can't always remember how my Plan 9 (legacy) system is different from the 
distribution, but it runs Go (tip) more than adequately (I actually have two 
production systems).

Installing from CD isn't always successful, even from David's legacy site. I 
did have to make some allowance for the ESX 3.5i instance that is running as 
fumble.proxima.alt.za.

Lucio.

[9fans] Go on Plan 9?

[Sean Caron]

Hi all,

I've been getting interested in programming in Go recently and it's my
understanding that at some point in time, Plan 9 was a supported
environment in which one could bootstrap and use Go?

I've tried a few different versions; 1.2.2, 1.4.2, 1.5.2, just following
the directions that I found on a blog somewhere, i.e:

tar xf go 1.4.2.tar
cd go-go1.4.2/src
./all.rc

But it fails almost immediately trying to bootstrap Go:

cpu% ./all.rc
# Building C bootstrap tool.
cmd/dist

# Building compilers and Go bootstrap tool for host, plan9/386.
lib9
cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:226
/usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
/usr/scaron/go-go1.4.2/include/plan9/utf.h:5
/usr/scaron/go-go1.4.2/include/plan9/../fmt.h:21
/usr/scaron/go-go1.4.2/include/plan9/fmt.h:5
/usr/scaron/go-go1.4.2/include/plan9/libc.h:6
/usr/scaron/go-go1.4.2/src/lib9/flag.c:6 Unterminated string or char const

I get a fair number of these errors for various header files, then some
more worrisome output:

/usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
external redeclaration of: Rune
TYPEDEF UINT
/usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
TYPEDEF USHORT
/386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:21]
/usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
external redeclaration of: Rune
TYPEDEF UINT
/usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
TYPEDEF USHORT
/386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/flag.c:22]
cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:227
/usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
/usr/scaron/go-go1.4.2/include/plan9/utf.h:5
/usr/scaron/go-go1.4.2/include/plan9/libc.h:7
/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:20 Unterminated string or
char const
go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
-D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
-I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
/usr/scaron/go-go1.4.2/src/lib9 -o $WORK/dorfmt.8
/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:
'/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
-D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
-I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
/usr/scaron/go-go1.4.2/src/lib9 -o $WORK/flag.8
/usr/scaron/go-go1.4.2/src/lib9/flag.c:
'/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:227
/usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
/usr/scaron/go-go1.4.2/include/plan9/utf.h:5
/usr/scaron/go-go1.4.2/include/plan9/libc.h:7
/usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:20 Unterminated string or char
const
/usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:152]
external redeclaration of: Rune
TYPEDEF UINT
/usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:152]
TYPEDEF USHORT
/386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:21]
/usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:152]
external redeclaration of: Rune
TYPEDEF UINT
/usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:152]
TYPEDEF USHORT
/386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:21]
go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
-D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
-I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
/usr/scaron/go-go1.4.2/src/lib9 -o $WORK/charstod.8
/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:
'/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
-D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
-I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
/usr/scaron/go-go1.4.2/src/lib9 -o $WORK/dofmt.8
/usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:
'/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist

At that point the build fails and I drop back to the rc prompt.

While the example I cite above is for version 1.4.2, I believe the failure
mode is pretty much the same for both earlier and later versions that I've
tried to build.

Is my Plan 9 installation "too old"? I'm using pretty bog-standard Fourth
Edition on this particular instance; 9atom doesn't seem to get along with
VMware ESXi (at least, not last time I checked).

Any help greatly appreciated! I'd love to be able to use Go within Plan 9.

Thanks,

Sean

Re: [9fans] Go on Plan 9?

[sl]

>From http://fqa.9front.org/appendixl.html:

# automatically converted ca certs from mozilla.org
hget http://curl.haxx.se/ca/cacert.pem >/sys/lib/tls/ca.pem
# shell script that emulates git commands
hget http://9front.org/extra/rc/git >$home/bin/rc/git
chmod 775 $home/bin/rc/git
# fetch the repository
git clone https://go.googlesource.com/go
cd go
git checkout go1.4.2
# build go
cd src
./make.rc
# install documentation
go get golang.org/x/tools/cmd/godoc
# go!

Newer versions of go seem to have problems with Plan 9.

sl

Re: [9fans] Go on Plan 9?

[Kenny Lasse Hoff Levinsen]

Go builds just fine right now on the plan9 builders: http://build.golang.org

1.4 and 1.5 are very different, due to 1.5 being written in Go. i386 and amd64 
should both build, although amd64 fails an irrelevant unittest.

What do you see with 1.5.2/1.5.3? (You said you tried?)

Best regards,
Kenny Levinsen // joushou

> On 26 Jan 2016, at 22:52, s...@9front.org wrote:
> 
> From http://fqa.9front.org/appendixl.html:
> 
>   # automatically converted ca certs from mozilla.org
>   hget http://curl.haxx.se/ca/cacert.pem >/sys/lib/tls/ca.pem
>   # shell script that emulates git commands
>   hget http://9front.org/extra/rc/git >$home/bin/rc/git
>   chmod 775 $home/bin/rc/git
>   # fetch the repository
>   git clone https://go.googlesource.com/go
>   cd go
>   git checkout go1.4.2
>   # build go
>   cd src
>   ./make.rc
>   # install documentation
>   go get golang.org/x/tools/cmd/godoc
>   # go!
> 
> Newer versions of go seem to have problems with Plan 9.
> 
> sl
> 

Re: [9fans] Go on Plan 9?

[Skip Tavakkolian]

All the errors seem related to the old Rune size. I suspect you're running
an old system and it's likely to not have nsec and tsemacquire syscalls
either.

If you believe the system is up-to-date, you can cross compile a simple Go
program using 1.5 or later targeting GOOS=plan9 GOARCH=386 from a Linux/OSX
or Windows box and see if it runs on your system.  That might give you more
info.



On Tue, Jan 26, 2016 at 1:44 PM Sean Caron  wrote:

> Hi all,
>
> I've been getting interested in programming in Go recently and it's my
> understanding that at some point in time, Plan 9 was a supported
> environment in which one could bootstrap and use Go?
>
> I've tried a few different versions; 1.2.2, 1.4.2, 1.5.2, just following
> the directions that I found on a blog somewhere, i.e:
>
> tar xf go 1.4.2.tar
> cd go-go1.4.2/src
> ./all.rc
>
> But it fails almost immediately trying to bootstrap Go:
>
> cpu% ./all.rc
> # Building C bootstrap tool.
> cmd/dist
>
> # Building compilers and Go bootstrap tool for host, plan9/386.
> lib9
> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:226
> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
> /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
> /usr/scaron/go-go1.4.2/include/plan9/../fmt.h:21
> /usr/scaron/go-go1.4.2/include/plan9/fmt.h:5
> /usr/scaron/go-go1.4.2/include/plan9/libc.h:6
> /usr/scaron/go-go1.4.2/src/lib9/flag.c:6 Unterminated string or char const
>
> I get a fair number of these errors for various header files, then some
> more worrisome output:
>
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
> external redeclaration of: Rune
> TYPEDEF UINT
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
> TYPEDEF USHORT
> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:21]
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
> external redeclaration of: Rune
> TYPEDEF UINT
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
> TYPEDEF USHORT
> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/flag.c:22]
> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:227
> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
> /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
> /usr/scaron/go-go1.4.2/include/plan9/libc.h:7
> /usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:20 Unterminated string or
> char const
> go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
> -D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
> -I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
> /usr/scaron/go-go1.4.2/src/lib9 -o $WORK/dorfmt.8
> /usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:
> '/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
> go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
> -D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
> -I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
> /usr/scaron/go-go1.4.2/src/lib9 -o $WORK/flag.8
> /usr/scaron/go-go1.4.2/src/lib9/flag.c:
> '/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:227
> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
> /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
> /usr/scaron/go-go1.4.2/include/plan9/libc.h:7
> /usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:20 Unterminated string or char
> const
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:152]
> external redeclaration of: Rune
> TYPEDEF UINT
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:152]
> TYPEDEF USHORT
> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:21]
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:152]
> external redeclaration of: Rune
> TYPEDEF UINT
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:152]
> TYPEDEF USHORT
> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:21]
> go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
> -D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
> -I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
> /usr/scaron/go-go1.4.2/src/lib9 -o $WORK/charstod.8
> /usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:
> '/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
> go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
> -D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
> -I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
> /usr/scaron/go-go1.4.2/src/lib9 -o $WORK/dofmt.8
> /usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:
> 

Re: [9fans] Go on Plan 9?

[Sean Caron]

Thanks, Skip. That would follow; this system is probably straight Fourth
Edition, certainly an old ISO...

I've never been 100% clear on the process for running updates; can I bring
myself up to current from where I'm at now and not have to reload or build
a fresh system? It's a VM and I can snapshot so I'm willing to give
anything a try ...

I'm looking at the directions in a (cached copy) of
http://plan9.bell-labs.com/wiki/plan9/Staying_up_to_date/index.html...

Is that still valid? What's the canonical procedure these days for updating
a system?

If that's roughly correct ... I'm running a single Plan 9 machine, combined
CPU and fileserver ... I run that command as the bootes user on the system
console?

Thanks!

Sean


On Tue, Jan 26, 2016 at 5:05 PM, Skip Tavakkolian <
skip.tavakkol...@gmail.com> wrote:

> All the errors seem related to the old Rune size. I suspect you're running
> an old system and it's likely to not have nsec and tsemacquire syscalls
> either.
>
> If you believe the system is up-to-date, you can cross compile a simple Go
> program using 1.5 or later targeting GOOS=plan9 GOARCH=386 from a Linux/OSX
> or Windows box and see if it runs on your system.  That might give you more
> info.
>
>
>
> On Tue, Jan 26, 2016 at 1:44 PM Sean Caron  wrote:
>
>> Hi all,
>>
>> I've been getting interested in programming in Go recently and it's my
>> understanding that at some point in time, Plan 9 was a supported
>> environment in which one could bootstrap and use Go?
>>
>> I've tried a few different versions; 1.2.2, 1.4.2, 1.5.2, just following
>> the directions that I found on a blog somewhere, i.e:
>>
>> tar xf go 1.4.2.tar
>> cd go-go1.4.2/src
>> ./all.rc
>>
>> But it fails almost immediately trying to bootstrap Go:
>>
>> cpu% ./all.rc
>> # Building C bootstrap tool.
>> cmd/dist
>>
>> # Building compilers and Go bootstrap tool for host, plan9/386.
>> lib9
>> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:226
>> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
>> /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
>> /usr/scaron/go-go1.4.2/include/plan9/../fmt.h:21
>> /usr/scaron/go-go1.4.2/include/plan9/fmt.h:5
>> /usr/scaron/go-go1.4.2/include/plan9/libc.h:6
>> /usr/scaron/go-go1.4.2/src/lib9/flag.c:6 Unterminated string or char const
>>
>> I get a fair number of these errors for various header files, then some
>> more worrisome output:
>>
>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
>> external redeclaration of: Rune
>> TYPEDEF UINT
>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
>> TYPEDEF USHORT
>> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:21]
>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
>> external redeclaration of: Rune
>> TYPEDEF UINT
>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
>> TYPEDEF USHORT
>> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/flag.c:22]
>> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:227
>> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
>> /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
>> /usr/scaron/go-go1.4.2/include/plan9/libc.h:7
>> /usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:20 Unterminated string or
>> char const
>> go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
>> -D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
>> -I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
>> /usr/scaron/go-go1.4.2/src/lib9 -o $WORK/dorfmt.8
>> /usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:
>> '/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
>> go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
>> -D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
>> -I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
>> /usr/scaron/go-go1.4.2/src/lib9 -o $WORK/flag.8
>> /usr/scaron/go-go1.4.2/src/lib9/flag.c:
>> '/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
>> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:227
>> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
>> /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
>> /usr/scaron/go-go1.4.2/include/plan9/libc.h:7
>> /usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:20 Unterminated string or char
>> const
>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:152]
>> external redeclaration of: Rune
>> TYPEDEF UINT
>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:152]
>> TYPEDEF USHORT
>> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:21]
>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:152]
>> external 

Re: [9fans] Go on Plan 9?

[David du Colombier]

> All the errors seem related to the old Rune size. I suspect you're running
> an old system and it's likely to not have nsec and tsemacquire syscalls
> either.
>
> If you believe the system is up-to-date, you can cross compile a simple Go
> program using 1.5 or later targeting GOOS=plan9 GOARCH=386 from a Linux/OSX
> or Windows box and see if it runs on your system.  That might give you more
> info.

Yes, Skip is right. On your system Rune is defined as ushort instead of uint.
The change from ushort to uint was done in April 2013.

While you could successfully cross-compile Go 1.5, it will probably
not work on your machine. In fact, the nsec system call will likely be
missing as well, since it was introduced in Plan 9 in May 2014.

You should update your system.

Since plan9.bell-labs.com is currently down, you could either change
your 9fs script and change it to pull from 9p.io, like this:

http://9legacy.org/9legacy/patch/9fs-9p.io.diff

Or use the latest Plan 9 CD image:

http://9p.io/plan9/download/plan9.iso.bz2

Then, you will be able to compile and execute Go 1.4, 1.5 and 1.6 successfully.

-- 
David du Colombier

Re: [9fans] Go on Plan 9?

[sl]

> Go builds just fine right now on the plan9 builders: http://build.golang.org
> 
> 1.4 and 1.5 are very different, due to 1.5 being written in Go. i386 and 
> amd64 should both build, although amd64 fails an irrelevant unittest.
> 
> What do you see with 1.5.2/1.5.3? (You said you tried?)

Note: I'm running 9front. I can build on amd64 but not 386. Last attempt
was 1.5 on 386, bootstrapped with 1.4.2:

dl; go version
go version go1.4.2 plan9/386
dl; GOROOT_BOOTSTRAP=/usr/local/go
dl; ./make.rc
# Building Go bootstrap tool.
cmd/dist

# Building Go toolchain using /usr/local/go.
bootstrap/internal/obj
bootstrap/asm/internal/flags
bootstrap/compile/internal/big
bootstrap/internal/obj/arm
bootstrap/internal/obj/arm64
bootstrap/internal/obj/ppc64
bootstrap/internal/obj/x86
bootstrap/asm/internal/lex
bootstrap/asm/internal/arch
bootstrap/internal/gcprog
bootstrap/compile/internal/gc
bootstrap/asm/internal/asm
bootstrap/asm
bootstrap/link/internal/ld
bootstrap/compile/internal/amd64
bootstrap/compile/internal/arm
bootstrap/compile/internal/arm64
bootstrap/compile/internal/ppc64
bootstrap/compile/internal/x86
bootstrap/link/internal/amd64
bootstrap/compile
bootstrap/link/internal/arm
bootstrap/link/internal/arm64
bootstrap/link/internal/ppc64
bootstrap/link/internal/x86
bootstrap/link

# Building go_bootstrap for host, plan9/386.
runtime
panic: runtime error: floating point error
[signal 0x5 code=0x18837950 addr=0x8e826 pc=0x1f3f87]

goroutine 1 [running]:
bootstrap/compile/internal/big.nat.string(0x10b52000, 0x10, 0x16, 
0x3511a8, 0xa, 0x0, 0x0)

/usr/local/386/go1.5/src/cmd/compile/internal/big/natconv.go:265 +0x117
bootstrap/compile/internal/big.nat.decimalString(0x10b52000, 0x10, 
0x16, 0x0, 0x0)

/usr/local/386/go1.5/src/cmd/compile/internal/big/natconv.go:241 +0x6c
bootstrap/compile/internal/big.(*Float).fmtB(0x10b769c0, 0x154f35a0, 
0x0, 0xa, 0x0, 0x0, 0x0)
/usr/local/386/go1.5/src/cmd/compile/internal/big/ftoa.go:258 
+0x136
bootstrap/compile/internal/big.(*Float).Append(0x10b769c0, 0x154f35a0, 
0x0, 0xa, 0x62, 0x0, 0x0, 0x0, 0x0)
/usr/local/386/go1.5/src/cmd/compile/internal/big/ftoa.go:73 
+0x249
bootstrap/compile/internal/big.(*Float).Text(0x10b769c0, 0x154f3562, 
0x0, 0x0, 0x0)
/usr/local/386/go1.5/src/cmd/compile/internal/big/ftoa.go:46 
+0x98
bootstrap/compile/internal/gc.Fconv(0x10b769c0, 0x0, 0x0, 0x0)

/usr/local/386/go1.5/src/cmd/compile/internal/gc/mparith3.go:208 +0x6b
bootstrap/compile/internal/gc.Vconv(0x2f0360, 0x10b769c0, 0x8, 0x0, 0x0)
/usr/local/386/go1.5/src/cmd/compile/internal/gc/fmt.go:327 
+0x544
bootstrap/compile/internal/gc.dumpasmhdr()
/usr/local/386/go1.5/src/cmd/compile/internal/gc/export.go:544 
+0x748
bootstrap/compile/internal/gc.Main()
/usr/local/386/go1.5/src/cmd/compile/internal/gc/lex.go:495 
+0x19c0
bootstrap/compile/internal/x86.Main()
/usr/local/386/go1.5/src/cmd/compile/internal/x86/galign.go:108 
+0x5ff
main.main()
/usr/local/386/go1.5/src/cmd/compile/main.go:24 +0x9a
go tool dist: FAILED: /usr/local/386/go1.5/pkg/tool/plan9_386/compile 
-pack -o /tmp/go-tool-dist-289352163/_go_.a -p runtime -+ -asmhdr 
/tmp/go-tool-dist-289352163/go_asm.h /usr/local/386/go1.5/src/runtime/alg.go 
/usr/local/386/go1.5/src/runtime/arch1_386.go 
/usr/local/386/go1.5/src/runtime/arch_386.go 
/usr/local/386/go1.5/src/runtime/atomic_386.go 
/usr/local/386/go1.5/src/runtime/atomic_pointer.go 
/usr/local/386/go1.5/src/runtime/cgo.go 
/usr/local/386/go1.5/src/runtime/cgocall.go 
/usr/local/386/go1.5/src/runtime/cgocallback.go 
/usr/local/386/go1.5/src/runtime/chan.go 
/usr/local/386/go1.5/src/runtime/compiler.go 
/usr/local/386/go1.5/src/runtime/complex.go 
/usr/local/386/go1.5/src/runtime/cpuprof.go 
/usr/local/386/go1.5/src/runtime/cputicks.go 
/usr/local/386/go1.5/src/runtime/debug.go 
/usr/local/386/go1.5/src/runtime/defs_plan9_386.go 
/usr/local/386/go1.5/src/runtime/env_plan9.go 
/usr/local/386/go1.5/src/runtime/error.go 
/usr/local/386/go1.5/src/runtime/extern.go /usr/local/386/go1.5
 /src/runtime/hash32.go /usr/local/386/go1.5/src/runtime/hashmap.go 
/usr/local/386/go1.5/src/runtime/hashmap_fast.go 
/usr/local/386/go1.5/src/runtime/heapdump.go 
/usr/local/386/go1.5/src/runtime/iface.go 
/usr/local/386/go1.5/src/runtime/lfstack.go 
/usr/local/386/go1.5/src/runtime/lfstack_32bit.go 
/usr/local/386/go1.5/src/runtime/lock_sema.go 
/usr/local/386/go1.5/src/runtime/malloc.go 

Re: [9fans] Go on Plan 9?

[David du Colombier]

> I'm looking at the directions in a (cached copy) of
> http://plan9.bell-labs.com/wiki/plan9/Staying_up_to_date/index.html...
>
> Is that still valid? What's the canonical procedure these days for updating
> a system?
>
> If that's roughly correct ... I'm running a single Plan 9 machine, combined
> CPU and fileserver ... I run that command as the bootes user on the system
> console?

This is a bit more complicated because of two reasons:

1. The plan9.bell-labs.com server is currently down.
2. Your system is too old, and running the new binaries will require
   a new kernel with the nsec syscall.

I think the easiest for you would be to apply this patch:

% hget http://9legacy.org/9legacy/patch/9fs-9p.io.diff | ape/patch -p0

Then, install the new kernel binaries to get the new nsec syscall:

% 9fs sources
% 9fat:
% cp /n/sources/plan9/386/9pcf /n/9fat
% cp /n/sources/plan9/386/9pccpu /n/9fat
% hget http://www.9legacy.org/download/kernel/9pccpuf >/n/9fat
% unmount /n/9fat

Then, reboot your machine to run the new kernel.

Finally, update your system:

% /usr/glenda/bin/rc/pull

-- 
David du Colombier

Re: [9fans] Go on Plan 9?

[David du Colombier]

> Note: I'm running 9front. I can build on amd64 but not 386. Last attempt
> was 1.5 on 386, bootstrapped with 1.4.2:
>
> dl; go version
> go version go1.4.2 plan9/386
> dl; GOROOT_BOOTSTRAP=/usr/local/go
> dl; ./make.rc
> # Building Go bootstrap tool.
> cmd/dist
>
> # Building Go toolchain using /usr/local/go.
> bootstrap/internal/obj
> bootstrap/asm/internal/flags
> bootstrap/compile/internal/big
> bootstrap/internal/obj/arm
> bootstrap/internal/obj/arm64
> bootstrap/internal/obj/ppc64
> bootstrap/internal/obj/x86
> bootstrap/asm/internal/lex
> bootstrap/asm/internal/arch
> bootstrap/internal/gcprog
> bootstrap/compile/internal/gc
> bootstrap/asm/internal/asm
> bootstrap/asm
> bootstrap/link/internal/ld
> bootstrap/compile/internal/amd64
> bootstrap/compile/internal/arm
> bootstrap/compile/internal/arm64
> bootstrap/compile/internal/ppc64
> bootstrap/compile/internal/x86
> bootstrap/link/internal/amd64
> bootstrap/compile
> bootstrap/link/internal/arm
> bootstrap/link/internal/arm64
> bootstrap/link/internal/ppc64
> bootstrap/link/internal/x86
> bootstrap/link
>
> # Building go_bootstrap for host, plan9/386.
> runtime
> panic: runtime error: floating point error
> [signal 0x5 code=0x18837950 addr=0x8e826 pc=0x1f3f87]
>
> goroutine 1 [running]:
> bootstrap/compile/internal/big.nat.string(0x10b52000, 0x10, 0x16, 
> 0x3511a8, 0xa, 0x0, 0x0)
> 
> /usr/local/386/go1.5/src/cmd/compile/internal/big/natconv.go:265 +0x117
> bootstrap/compile/internal/big.nat.decimalString(0x10b52000, 0x10, 
> 0x16, 0x0, 0x0)
> 
> /usr/local/386/go1.5/src/cmd/compile/internal/big/natconv.go:241 +0x6c
> bootstrap/compile/internal/big.(*Float).fmtB(0x10b769c0, 0x154f35a0, 
> 0x0, 0xa, 0x0, 0x0, 0x0)
> /usr/local/386/go1.5/src/cmd/compile/internal/big/ftoa.go:258 
> +0x136
> bootstrap/compile/internal/big.(*Float).Append(0x10b769c0, 
> 0x154f35a0, 0x0, 0xa, 0x62, 0x0, 0x0, 0x0, 0x0)
> /usr/local/386/go1.5/src/cmd/compile/internal/big/ftoa.go:73 
> +0x249
> bootstrap/compile/internal/big.(*Float).Text(0x10b769c0, 0x154f3562, 
> 0x0, 0x0, 0x0)
> /usr/local/386/go1.5/src/cmd/compile/internal/big/ftoa.go:46 
> +0x98
> bootstrap/compile/internal/gc.Fconv(0x10b769c0, 0x0, 0x0, 0x0)
> 
> /usr/local/386/go1.5/src/cmd/compile/internal/gc/mparith3.go:208 +0x6b
> bootstrap/compile/internal/gc.Vconv(0x2f0360, 0x10b769c0, 0x8, 0x0, 
> 0x0)
> /usr/local/386/go1.5/src/cmd/compile/internal/gc/fmt.go:327 
> +0x544
> bootstrap/compile/internal/gc.dumpasmhdr()
> 
> /usr/local/386/go1.5/src/cmd/compile/internal/gc/export.go:544 +0x748
> bootstrap/compile/internal/gc.Main()
> /usr/local/386/go1.5/src/cmd/compile/internal/gc/lex.go:495 
> +0x19c0
> bootstrap/compile/internal/x86.Main()
> 
> /usr/local/386/go1.5/src/cmd/compile/internal/x86/galign.go:108 +0x5ff
> main.main()
> /usr/local/386/go1.5/src/cmd/compile/main.go:24 +0x9a
> go tool dist: FAILED: /usr/local/386/go1.5/pkg/tool/plan9_386/compile 
> -pack -o /tmp/go-tool-dist-289352163/_go_.a -p runtime -+ -asmhdr 
> /tmp/go-tool-dist-289352163/go_asm.h /usr/local/386/go1.5/src/runtime/alg.go 
> /usr/local/386/go1.5/src/runtime/arch1_386.go 
> /usr/local/386/go1.5/src/runtime/arch_386.go 
> /usr/local/386/go1.5/src/runtime/atomic_386.go 
> /usr/local/386/go1.5/src/runtime/atomic_pointer.go 
> /usr/local/386/go1.5/src/runtime/cgo.go 
> /usr/local/386/go1.5/src/runtime/cgocall.go 
> /usr/local/386/go1.5/src/runtime/cgocallback.go 
> /usr/local/386/go1.5/src/runtime/chan.go 
> /usr/local/386/go1.5/src/runtime/compiler.go 
> /usr/local/386/go1.5/src/runtime/complex.go 
> /usr/local/386/go1.5/src/runtime/cpuprof.go 
> /usr/local/386/go1.5/src/runtime/cputicks.go 
> /usr/local/386/go1.5/src/runtime/debug.go 
> /usr/local/386/go1.5/src/runtime/defs_plan9_386.go 
> /usr/local/386/go1.5/src/runtime/env_plan9.go 
> /usr/local/386/go1.5/src/runtime/error.go 
> /usr/local/386/go1.5/src/runtime/extern.go /usr/local/386/go1.5
>  /src/runtime/hash32.go /usr/local/386/go1.5/src/runtime/hashmap.go 
> /usr/local/386/go1.5/src/runtime/hashmap_fast.go 
> /usr/local/386/go1.5/src/runtime/heapdump.go 
> /usr/local/386/go1.5/src/runtime/iface.go 
> /usr/local/386/go1.5/src/runtime/lfstack.go 
> /usr/local/386/go1.5/src/runtime/lfstack_32bit.go 
> /usr/local/386/go1.5/src/runtime/lock_sema.go 
> /usr/local/386/go1.5/src/runtime/malloc.go 
> /usr/local/386/go1.5/src/runtime/mbarrier.go 
> /usr/local/386/go1.5/src/runtime/mbitmap.go 
> 

Re: [9fans] Go on Plan 9?

[David du Colombier]

> % 9fs sources
> % 9fat:
> % cp /n/sources/plan9/386/9pcf /n/9fat
> % cp /n/sources/plan9/386/9pccpu /n/9fat
> % hget http://www.9legacy.org/download/kernel/9pccpuf >/n/9fat

Of course, I mean:

hget http://www.9legacy.org/download/kernel/9pccpuf >/n/9fat/9pccpuf

-- 
David du Colombier

Re: [9fans] Go on Plan 9?

[Matthew Veety]

Also the ports tree[1] version of golang should install fine. I haven't
tried it in a while, but also haven't changed it so it should work. That
will grab the ca certs and install (I think) 1.3.

--
Veety

Re: [9fans] Go on Plan 9?

[Sean Caron]

Answering my own silly question, on my fossil-based system, running the
following command on the console as the bootes user seems to get the update
process running:

replica/pull -v /dist/replica/network

I'll wait for this to complete and then give building Go another shot.
Thanks for answering my shot in the dark!

Thanks,

Sean


On Tue, Jan 26, 2016 at 5:16 PM, Sean Caron  wrote:

> Thanks, Skip. That would follow; this system is probably straight Fourth
> Edition, certainly an old ISO...
>
> I've never been 100% clear on the process for running updates; can I bring
> myself up to current from where I'm at now and not have to reload or build
> a fresh system? It's a VM and I can snapshot so I'm willing to give
> anything a try ...
>
> I'm looking at the directions in a (cached copy) of
> http://plan9.bell-labs.com/wiki/plan9/Staying_up_to_date/index.html...
>
> Is that still valid? What's the canonical procedure these days for
> updating a system?
>
> If that's roughly correct ... I'm running a single Plan 9 machine,
> combined CPU and fileserver ... I run that command as the bootes user on
> the system console?
>
> Thanks!
>
> Sean
>
>
> On Tue, Jan 26, 2016 at 5:05 PM, Skip Tavakkolian <
> skip.tavakkol...@gmail.com> wrote:
>
>> All the errors seem related to the old Rune size. I suspect you're
>> running an old system and it's likely to not have nsec and tsemacquire
>> syscalls either.
>>
>> If you believe the system is up-to-date, you can cross compile a simple
>> Go program using 1.5 or later targeting GOOS=plan9 GOARCH=386 from a
>> Linux/OSX or Windows box and see if it runs on your system.  That might
>> give you more info.
>>
>>
>>
>> On Tue, Jan 26, 2016 at 1:44 PM Sean Caron  wrote:
>>
>>> Hi all,
>>>
>>> I've been getting interested in programming in Go recently and it's my
>>> understanding that at some point in time, Plan 9 was a supported
>>> environment in which one could bootstrap and use Go?
>>>
>>> I've tried a few different versions; 1.2.2, 1.4.2, 1.5.2, just following
>>> the directions that I found on a blog somewhere, i.e:
>>>
>>> tar xf go 1.4.2.tar
>>> cd go-go1.4.2/src
>>> ./all.rc
>>>
>>> But it fails almost immediately trying to bootstrap Go:
>>>
>>> cpu% ./all.rc
>>> # Building C bootstrap tool.
>>> cmd/dist
>>>
>>> # Building compilers and Go bootstrap tool for host, plan9/386.
>>> lib9
>>> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:226
>>> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
>>> /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
>>> /usr/scaron/go-go1.4.2/include/plan9/../fmt.h:21
>>> /usr/scaron/go-go1.4.2/include/plan9/fmt.h:5
>>> /usr/scaron/go-go1.4.2/include/plan9/libc.h:6
>>> /usr/scaron/go-go1.4.2/src/lib9/flag.c:6 Unterminated string or char const
>>>
>>> I get a fair number of these errors for various header files, then some
>>> more worrisome output:
>>>
>>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
>>> external redeclaration of: Rune
>>> TYPEDEF UINT
>>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
>>> TYPEDEF USHORT
>>> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:21]
>>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
>>> external redeclaration of: Rune
>>> TYPEDEF UINT
>>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
>>> TYPEDEF USHORT
>>> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/flag.c:22]
>>> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:227
>>> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
>>> /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
>>> /usr/scaron/go-go1.4.2/include/plan9/libc.h:7
>>> /usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:20 Unterminated string or
>>> char const
>>> go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
>>> -D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
>>> -I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
>>> /usr/scaron/go-go1.4.2/src/lib9 -o $WORK/dorfmt.8
>>> /usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:
>>> '/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
>>> go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
>>> -D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
>>> -I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
>>> /usr/scaron/go-go1.4.2/src/lib9 -o $WORK/flag.8
>>> /usr/scaron/go-go1.4.2/src/lib9/flag.c:
>>> '/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
>>> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:227
>>> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
>>> /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
>>> /usr/scaron/go-go1.4.2/include/plan9/libc.h:7
>>> /usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:20 Unterminated string or 

Re: [9fans] Go on Plan 9?

[Skip Tavakkolian]

Sean,

David's (0intro) instructions are the right way to do it.  If I recall
correctly, if you want to update by rebuilding from updated sources,
there's a careful dance that needs to happen for the transition from old
Rune size to the new.  Geoff sent out a note to 9fans outlining the steps
at that time; you might be able to find it on 9fans archive (which
unfortunately is not what it used to be).

-Skip


On Tue, Jan 26, 2016 at 5:40 PM Sean Caron  wrote:

> Answering my own silly question, on my fossil-based system, running the
> following command on the console as the bootes user seems to get the update
> process running:
>
> replica/pull -v /dist/replica/network
>
> I'll wait for this to complete and then give building Go another shot.
> Thanks for answering my shot in the dark!
>
> Thanks,
>
> Sean
>
>
> On Tue, Jan 26, 2016 at 5:16 PM, Sean Caron  wrote:
>
>> Thanks, Skip. That would follow; this system is probably straight Fourth
>> Edition, certainly an old ISO...
>>
>> I've never been 100% clear on the process for running updates; can I
>> bring myself up to current from where I'm at now and not have to reload or
>> build a fresh system? It's a VM and I can snapshot so I'm willing to give
>> anything a try ...
>>
>> I'm looking at the directions in a (cached copy) of
>> http://plan9.bell-labs.com/wiki/plan9/Staying_up_to_date/index.html...
>>
>> Is that still valid? What's the canonical procedure these days for
>> updating a system?
>>
>> If that's roughly correct ... I'm running a single Plan 9 machine,
>> combined CPU and fileserver ... I run that command as the bootes user on
>> the system console?
>>
>> Thanks!
>>
>> Sean
>>
>>
>> On Tue, Jan 26, 2016 at 5:05 PM, Skip Tavakkolian <
>> skip.tavakkol...@gmail.com> wrote:
>>
>>> All the errors seem related to the old Rune size. I suspect you're
>>> running an old system and it's likely to not have nsec and tsemacquire
>>> syscalls either.
>>>
>>> If you believe the system is up-to-date, you can cross compile a simple
>>> Go program using 1.5 or later targeting GOOS=plan9 GOARCH=386 from a
>>> Linux/OSX or Windows box and see if it runs on your system.  That might
>>> give you more info.
>>>
>>>
>>>
>>> On Tue, Jan 26, 2016 at 1:44 PM Sean Caron  wrote:
>>>
 Hi all,

 I've been getting interested in programming in Go recently and it's my
 understanding that at some point in time, Plan 9 was a supported
 environment in which one could bootstrap and use Go?

 I've tried a few different versions; 1.2.2, 1.4.2, 1.5.2, just
 following the directions that I found on a blog somewhere, i.e:

 tar xf go 1.4.2.tar
 cd go-go1.4.2/src
 ./all.rc

 But it fails almost immediately trying to bootstrap Go:

 cpu% ./all.rc
 # Building C bootstrap tool.
 cmd/dist

 # Building compilers and Go bootstrap tool for host, plan9/386.
 lib9
 cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:226
 /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
 /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
 /usr/scaron/go-go1.4.2/include/plan9/../fmt.h:21
 /usr/scaron/go-go1.4.2/include/plan9/fmt.h:5
 /usr/scaron/go-go1.4.2/include/plan9/libc.h:6
 /usr/scaron/go-go1.4.2/src/lib9/flag.c:6 Unterminated string or char const

 I get a fair number of these errors for various header files, then some
 more worrisome output:

 /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
 external redeclaration of: Rune
 TYPEDEF UINT
 /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
 TYPEDEF USHORT
 /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:21]
 /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
 external redeclaration of: Rune
 TYPEDEF UINT
 /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
 TYPEDEF USHORT
 /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/flag.c:22]
 cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:227
 /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
 /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
 /usr/scaron/go-go1.4.2/include/plan9/libc.h:7
 /usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:20 Unterminated string or
 char const
 go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
 -D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
 -I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
 /usr/scaron/go-go1.4.2/src/lib9 -o $WORK/dorfmt.8
 /usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:
 '/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
 go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 

Re: [9fans] Go on Plan 9?

[Sean Caron]

Yeah, thank goodness for snapshots :O Running replica/pull didn't turn out
so good for my current running system. It looks like it might make the most
sense to just archive my home directory and reload a fresh VM ...

Where are they keeping the most current installation ISO these days? I'm
just not sure of what's canonical now that the old bell-labs.com domain is
offline.

Thanks!

Sean


On Tue, Jan 26, 2016 at 8:52 PM, Skip Tavakkolian <
skip.tavakkol...@gmail.com> wrote:

> Sean,
>
> David's (0intro) instructions are the right way to do it.  If I recall
> correctly, if you want to update by rebuilding from updated sources,
> there's a careful dance that needs to happen for the transition from old
> Rune size to the new.  Geoff sent out a note to 9fans outlining the steps
> at that time; you might be able to find it on 9fans archive (which
> unfortunately is not what it used to be).
>
> -Skip
>
>
> On Tue, Jan 26, 2016 at 5:40 PM Sean Caron  wrote:
>
>> Answering my own silly question, on my fossil-based system, running the
>> following command on the console as the bootes user seems to get the update
>> process running:
>>
>> replica/pull -v /dist/replica/network
>>
>> I'll wait for this to complete and then give building Go another shot.
>> Thanks for answering my shot in the dark!
>>
>> Thanks,
>>
>> Sean
>>
>>
>> On Tue, Jan 26, 2016 at 5:16 PM, Sean Caron  wrote:
>>
>>> Thanks, Skip. That would follow; this system is probably straight Fourth
>>> Edition, certainly an old ISO...
>>>
>>> I've never been 100% clear on the process for running updates; can I
>>> bring myself up to current from where I'm at now and not have to reload or
>>> build a fresh system? It's a VM and I can snapshot so I'm willing to give
>>> anything a try ...
>>>
>>> I'm looking at the directions in a (cached copy) of
>>> http://plan9.bell-labs.com/wiki/plan9/Staying_up_to_date/index.html...
>>>
>>> Is that still valid? What's the canonical procedure these days for
>>> updating a system?
>>>
>>> If that's roughly correct ... I'm running a single Plan 9 machine,
>>> combined CPU and fileserver ... I run that command as the bootes user on
>>> the system console?
>>>
>>> Thanks!
>>>
>>> Sean
>>>
>>>
>>> On Tue, Jan 26, 2016 at 5:05 PM, Skip Tavakkolian <
>>> skip.tavakkol...@gmail.com> wrote:
>>>
 All the errors seem related to the old Rune size. I suspect you're
 running an old system and it's likely to not have nsec and tsemacquire
 syscalls either.

 If you believe the system is up-to-date, you can cross compile a simple
 Go program using 1.5 or later targeting GOOS=plan9 GOARCH=386 from a
 Linux/OSX or Windows box and see if it runs on your system.  That might
 give you more info.



 On Tue, Jan 26, 2016 at 1:44 PM Sean Caron  wrote:

> Hi all,
>
> I've been getting interested in programming in Go recently and it's my
> understanding that at some point in time, Plan 9 was a supported
> environment in which one could bootstrap and use Go?
>
> I've tried a few different versions; 1.2.2, 1.4.2, 1.5.2, just
> following the directions that I found on a blog somewhere, i.e:
>
> tar xf go 1.4.2.tar
> cd go-go1.4.2/src
> ./all.rc
>
> But it fails almost immediately trying to bootstrap Go:
>
> cpu% ./all.rc
> # Building C bootstrap tool.
> cmd/dist
>
> # Building compilers and Go bootstrap tool for host, plan9/386.
> lib9
> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:226
> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
> /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
> /usr/scaron/go-go1.4.2/include/plan9/../fmt.h:21
> /usr/scaron/go-go1.4.2/include/plan9/fmt.h:5
> /usr/scaron/go-go1.4.2/include/plan9/libc.h:6
> /usr/scaron/go-go1.4.2/src/lib9/flag.c:6 Unterminated string or char const
>
> I get a fair number of these errors for various header files, then
> some more worrisome output:
>
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
> external redeclaration of: Rune
> TYPEDEF UINT
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
> TYPEDEF USHORT
> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:21]
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
> external redeclaration of: Rune
> TYPEDEF UINT
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
> TYPEDEF USHORT
> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/flag.c:22]
> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:227
> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
> 

[9fans] Go and Plan 9 (Was: abuse reporting format?)

[Lucio De Re]

 I've been toying with the idea of re-implementing a SPAM reporting
 system in Go under Plan 9

I will be posting to sources my mostly functional release of Go for
Plan 9.  I have successfully generated godoc using entirely a Plan 9
platform and my next step is to make sure that this can be reproduced
in a somewhat cleaner environment,

There's a lot of administrative effort required, but I think I have
very solid foundations now.

I will post here when the new release is available on sources.

++L