> The following executables are installed into $GOROOT/bin as Plan 9
> a.out binaries when you run make -k install inside src/pkg:
> cgo, ebnflint, gofix, gofmt, gotest, gotype, govet, goyacc, hgpatch.
> They should be directed somewhere else by setting GOBIN, there is no
> need to include them in
The following executables are installed into $GOROOT/bin as Plan 9
a.out binaries when you run make -k install inside src/pkg:
cgo, ebnflint, gofix, gofmt, gotest, gotype, govet, goyacc, hgpatch.
They should be directed somewhere else by setting GOBIN, there is no
need to include them in your PATH,
> The new build incantation is:
>
> cd $GOROOT/src/pkg
> make clean
> mkdir -p $GROOT/bin/plan9
> GOOS=plan9 GOBIN=$GOROOT/bin/plan9 make -k install
I won't try this until the mmap problem you refer to is resolved, so a
question is in order: are the plan 9 tools essential to the operation
of 8l w
Sorry, Skip was right.. It looks like make install in src/pkg will
also build and overwrite some of the cmd tools already in your GOBIN
with Plan 9 a.out. This is probably not what you were looking for.
The new build incantation is:
cd $GOROOT/src/pkg
make clean
mkdir -p $GROOT/bin/plan9
GOOS=plan
Great info! thanks.
-Skip
On Sat, Apr 9, 2011 at 11:53 AM, Pavel Zholkover wrote:
> The mainline go will not compile syscall after the last post-weekly tag due
> to the mmap support.
> Russ wrote he'll look into it next week.
>
> I try to maintain the bitbucket patch que with CLs still being revi
The mainline go will not compile syscall after the last post-weekly tag due
to the mmap support.
Russ wrote he'll look into it next week.
I try to maintain the bitbucket patch que with CLs still being reviewed
(Anthony's time changes for example) so people can test them as a whole.
There is no ne
Try make -k install like in the wiki instructions. This should continue
building packages even if some fail to compile.
On Apr 9, 2011 8:53 PM, "Sergey Kish" wrote:
> Hello,
>
> I'm unable to make go plan9 crosscompiler.
> Can you help me?
>
> # I use patched repo
> hg qclone https://bitbucket.or
is there a reason you didn't build it from the official Go sources?
i only needed to make a couple of tweaks (see the patch below) to
build it. a couple of things to watch out for:
- make sure you have two different GOBIN's; one for your local Linux
box and the other for making the Plan 9 binarie
Hello,
I'm unable to make go plan9 crosscompiler.
Can you help me?
# I use patched repo
hg qclone https://bitbucket.org/paulzhol/golang-plan9-runtime-patches go
cd go
hg qpush -a
# build as usual
export GOROOT=`pwd`
export GOOS=linux
export GOBIN="$GOROOT/bin"
export PATH="$GOBIN:$PATH"
mkdir -
Sent from my iPhone
On Apr 6, 2011, at 1:27 PM, "Joel C. Salomon" wrote:
> On Tuesday, April 5, 2011 1:33:30 PM UTC-4, David Leimbach wrote:
>> What we need is an OS port of Plan 9 to Go that can run hosted on another OS
>> or natively.
>>
>> InfernGo?
>
> Fuego.
>
+9!
> --Joel
>
On Tue, Apr 05, 2011 at 10:06:49PM +0300, Yaroslav wrote:
>
> Why not to run Go directly on your Ubuntu laptop – without the 9vx
> abstraction?
Because I'm a Plan 9 fan? I use Ubuntu only because of limitations in
Plan 9. Unfortunately, most of these limitations are going to be with
us for a l
On Tuesday, April 5, 2011 1:33:30 PM UTC-4, David Leimbach wrote:
> What we need is an OS port of Plan 9 to Go that can run hosted on another OS
> or natively.
>
> InfernGo?
Fuego.
--Joel
the point is that if the linuxemu is provisioned properly (gmake, gcc,
bash) to build the Plan 9 $GOBIN from source, then there wont be a
need for a linux build box, or porting and maintaining gmake, gcc,
bash, etc. one could also build Plan 9 binaries under linuxemu.
options as i see them are:
1
So I can write go programs that take advantage of private namespaces and
other Plan9 innovations.
Paul
On Tue, Apr 5, 2011 at 12:06 PM, Yaroslav wrote:
> 2011/4/5 Lucio De Re :
> > As for not running Go on 9vx, that's a pain, I have such a nice 9vx
> > installation on my Ubuntu 32-bit laptop th
leim...@gmail.com:
> r...@swtch.com:
>> What we need is an OS port of Plan 9 to Go that can run hosted on another OS
>> or natively.
> InfernGo?
Seconded, or at least Acme SAC-n-Go. I'd rather use Go than Limbo,
and I'd much rather only compile Go executables once.
Jason Catena
2011/4/5 Lucio De Re :
> As for not running Go on 9vx, that's a pain, I have such a nice 9vx
> installation on my Ubuntu 32-bit laptop that it almost fools me into
> believing it's Plan 9. I don't always have a convenient CPU server at
> hand to run Go on it.
Why not to run Go directly on your Ub
2011/4/5 andrey mirtchovski
> > InfernGo?
>
> Goribund ;)
>
>
What a positive sounding project name!
> InfernGo?
Goribund ;)
On Tue, Apr 5, 2011 at 10:36 AM, erik quanstrom wrote:
> > > What we need is an OS port of Plan 9 to Go that can run hosted on
> another
> > OS or natively.
> >
> > InfernGo?
>
> huh?
>
> - erik
>
>
Inferno-like Go based OS (instead of Limbo??)
Not necessarily with any kind of virtual machine but
> > What we need is an OS port of Plan 9 to Go that can run hosted on another
> OS or natively.
>
> InfernGo?
huh?
- erik
On Mon, Apr 4, 2011 at 10:11 PM, Russ Cox wrote:
> > All that Microsoft thinking (99.9%-thinking, if you find the other label
> > offensive) to avoid adding a minute, one-off change to the Go runtime?
>
> It is not a minute, one-off change.
> I don't know how to fix it to cope with tiny virtual a
On Tue, Apr 5, 2011 at 8:48 AM, ron minnich wrote:
> On Mon, Apr 4, 2011 at 10:11 PM, Russ Cox wrote:
>
>> The best answer might be to make USTKTOP 1GB.
>
>
>
> Agreed.
My latest vx32 has the change and:
term% ./8.out
hello world
so Go is go on 9vx
ron
On Mon, Apr 4, 2011 at 9:22 PM, Russ Cox wrote:
> The number of people who want to run Go on Plan 9
> is already small. The number of people who want to
> run Go on Plan 9 on 9vx is smaller yet. At that point
> why not just run Go directly?
>
> 9vx is a nice hack but still a hack.
>
> Russ
>
>
On Mon, Apr 4, 2011 at 10:11 PM, Russ Cox wrote:
> The best answer might be to make USTKTOP 1GB.
Agreed.
ron
Anthony Martin once said:
> -#define MaxArena32 (2U<<30)
> +#define MaxArena32 (240U<<20)
I forgot to mention this earlier but for the curious, I
used 240mb here because that is USTKTOP-USTKSIZE in 9vx.
Anthony
P.S.
Has anyone ran into the SEGMAPSIZE limit on native Plan 9?
The current value
On Tue, Apr 5, 2011 at 7:33 AM, Lucio De Re wrote:
> No, and no "yuck", either: Go executables are different animals and
> they are allowed to be identified as such. Until they are not, when
> they are allowed to become the same animal.
> snip...
>
> And maybe it's just me being uninformed, but I
>> The best answer might be to make USTKTOP 1GB.
>>
> Where?
In 9vx.
Russ
On Tue, Apr 05, 2011 at 01:11:35AM -0400, Russ Cox wrote:
>
> > All that Microsoft thinking (99.9%-thinking, if you find the other label
> > offensive) to avoid adding a minute, one-off change to the Go runtime?
>
> It is not a minute, one-off change.
I stand corrected.
> I don't know how to fi
> All that Microsoft thinking (99.9%-thinking, if you find the other label
> offensive) to avoid adding a minute, one-off change to the Go runtime?
It is not a minute, one-off change.
I don't know how to fix it to cope with tiny virtual address spaces
like those in 9vx. It's not something I antic
> No, and no "yuck", either: Go executables are different animals and
what's different about them? as far as i can tell, they're completely
standard.
- erik
On Mon, Apr 04, 2011 at 04:33:29PM -0400, erik quanstrom wrote:
>
[ ... ]
> then you can get rid of the old definitions in /*/include/u.h
> and declare a flag day. having both seems wrong to me.
> you might as well just do a local hack for the go stuff at that
> point.
>
> the hard part is convi
On Tue, Apr 05, 2011 at 12:22:18AM -0400, Russ Cox wrote:
> The number of people who want to run Go on Plan 9
> is already small. The number of people who want to
> run Go on Plan 9 on 9vx is smaller yet. At that point
> why not just run Go directly?
>
All that Microsoft thinking (99.9%-thinking
On Mon, Apr 04, 2011 at 04:10:15PM -0700, ron minnich wrote:
>
> On Mon, Apr 4, 2011 at 10:27 AM, Lucio De Re wrote:
>
> > May I suggest that we identify Go executables, because they may not run
> > under 9vx, as different from Plan 9 executables and adjust the Plan 9
> > kernel to identify thes
The number of people who want to run Go on Plan 9
is already small. The number of people who want to
run Go on Plan 9 on 9vx is smaller yet. At that point
why not just run Go directly?
9vx is a nice hack but still a hack.
Russ
I tried a simple hack on 9vx.
First, I had sysbrk_ return the max possible value instead of the
requested value. I.e., if go runtime asked for 768MB, I had it return
something less than TSTKTOP, which is around 256 MB. I like this
because if we change the USTKTOP on 9vx in future we don't have to
well, Russ has blessed the runtime fix :-)
I look forward to having go in 9vx too!
ron
> Sorry, Erik, I misunderstood your point.
no need to be sorry.
> I guess what you are pointing out is that on Plan 9, presumably, since
> the Go runtime is the only thing that might call brk(), it will always
> get a virtually contiguous heap. Therefore, instead of a huge upfront
> allocation, G
On Mon, Apr 4, 2011 at 10:27 AM, Lucio De Re wrote:
> May I suggest that we identify Go executables, because they may not run
> under 9vx, as different from Plan 9 executables and adjust the Plan 9
> kernel to identify these and avoid running them under 9vx?
um, yuck :-)
anyway, all you're say
On Mon, Apr 4, 2011 at 8:59 AM, erik quanstrom wrote:
> this is the whole point of the big allocation, so why
> would we drag this into plan 9, when it's not necessary.
> the plan 9 heap is contiguous.
Sorry, Erik, I misunderstood your point.
I guess what you are pointing out is that on Plan 9,
> term% diff /n/dump/2011/0130/386/include/u.h /n/dump/2011/0404/386/include/u.h
> 21a22,34
> > /* for the GO toolchain */
> > /* (with some effort this could go into /go/386/include,
> > but there's really no reason to keep it from the
> > native toolchain)
> > */
> > typedef char int8;
>
On Mon, Apr 04, 2011 at 07:27:28PM +0200, Lucio De Re wrote:
> On Mon, Apr 04, 2011 at 10:37:30AM +0300, Pavel Zholkover wrote:
> >
> > Thanks for the detailed explanation, I've added your patch to if that
> > is alright with you https://bitbucket.org/paulzhol/golang-plan9-
> > runtime-patches/
>
On Mon, Apr 04, 2011 at 10:18:12PM +0300, Pavel Zholkover wrote:
> On Mon, Apr 4, 2011 at 8:27 PM, Lucio De Re wrote:
> > PS: Would anybody like to summarise for us plebs whether there is any
> > convergence looming between Go and Plan 9 on the x64 front? It seems
> > sad to miss a chance to add
[Sorry for being quiet, I got unsubscribed from 9fans!]
> no, the shared libraries are not going to affect the heap size.
> Certainly not to this scale.
>
> My understanding was that Go used this large sparse address space to
> effect for its garbage collection; the fact that it is backed by mmap
On Mon, Apr 4, 2011 at 8:27 PM, Lucio De Re wrote:
> PS: Would anybody like to summarise for us plebs whether there is any
> convergence looming between Go and Plan 9 on the x64 front? It seems
> sad to miss a chance to add a peer-reviewed and thoroughly tested 64-bit
> toolchain to Plan 9.
the
On Mon, Apr 04, 2011 at 10:37:30AM +0300, Pavel Zholkover wrote:
>
> Thanks for the detailed explanation, I've added your patch to if that
> is alright with you https://bitbucket.org/paulzhol/golang-plan9-
> runtime-patches/
>
May I suggest that we identify Go executables, because they may not ru
On Mon Apr 4 11:19:37 EDT 2011, rminn...@gmail.com wrote:
> On Sun, Apr 3, 2011 at 2:24 PM, erik quanstrom
> wrote:
> >> The reason it doesn't work on 9vx is because the 32 bit Go runtime
> >> reserves a large chunk of address space (currently 768mb). On all
> >> other platforms, this is accomp
On Sun, Apr 3, 2011 at 2:24 PM, erik quanstrom wrote:
>> The reason it doesn't work on 9vx is because the 32 bit Go runtime
>> reserves a large chunk of address space (currently 768mb). On all
>> other platforms, this is accomplised with an mmap equivalient, which
>> we all know won't work on Pla
Thanks for the detailed explanation, I've added your patch to if that
is alright with you https://bitbucket.org/paulzhol/golang-plan9-
runtime-patches/
Pavel
On Mon, Apr 4, 2011 at 1:30 AM, Anthony Martin wrote:
> Pavel Zholkover once said:
>> I'm not sure I understand the reason 9vx will fail
Pavel Zholkover once said:
> I'm not sure I understand the reason 9vx will fail to reserve 768mb
> with brk() while my Plan 9 install on kvm+qemu with 128mb or ram works
> fine, as long as it is not written to.
The reason is because 9vx gives user processes a virtual
address space of only 256mb.
> The reason it doesn't work on 9vx is because the 32 bit Go runtime
> reserves a large chunk of address space (currently 768mb). On all
> other platforms, this is accomplised with an mmap equivalient, which
> we all know won't work on Plan 9.
>
if i read the thread on this topic correctly, this
I'm not sure I understand the reason 9vx will fail to reserve 768mb
with brk() while my Plan 9 install on kvm+qemu with 128mb or ram works
fine, as long as it is not written to.
The -s is no longer needed, 8l generates a.out symbols correctly.
Pavel
On Mon, Apr 4, 2011 at 12:16 AM, Anthony Marti
Anthony Martin once said:
> Right now, if you want to run Go binaries on Plan 9, you have to
> apply the patch at the bottom of this message. In the future we
> should probably have the runtime use the segment(3) device.
That should have been '9vx' instead of 'Plan 9'. Sorry.
Anthony
andrey mirtchovski once said:
> cross-compilation (GOOS=plan9, GOARCH=386, link with -s), but there
> are a few issues -- the build fails at crypto, so fmt is not compiled.
> for a hello world you need to manually make install pkg/strconv and
> pkg/reflect and pkg/fmt.
Everything works fine for m
On Sun, Apr 03, 2011 at 07:50:20PM +0100, Steve Simon wrote:
>
> A month or so ago I got the go compiler chain to build on plan9,
> port is too grand a term, it was just fixing a few nits.
>
That makes a third version. I seem to remember Erik's version compiled clean
and I have to ask Steve now
On Sun, Apr 03, 2011 at 11:20:25AM -0700, Rob Pike wrote:
>
> I'm not sure I follow. The 6c and 6g compilers in the Go distribution
> are compiled with the local compiler, such as gcc on Linux and OS X.
> I don't believe it's possible they have Plan 9-specific features in
> their source. I can b
A month or so ago I got the go compiler chain to build on plan9,
port is too grand a term, it was just fixing a few nits.
I wrote mkfiles and fixed a few minor bugs. The bigest problem was my knowledge
of yacc was not sufficent to rework the error generation magic go uses from
the bison based code
I'm not sure I follow. The 6c and 6g compilers in the Go distribution
are compiled with the local compiler, such as gcc on Linux and OS X.
I don't believe it's possible they have Plan 9-specific features in
their source. I can believe they would have problems compiling on
Plan 9, but that's the i
On Sun, Apr 03, 2011 at 01:43:53PM -0400, Devon H. O'Dell wrote:
>
> Does -fplan9-extensions not do that? Its in the latest gcc for gccgo...
That would be great. I don't even pretend to keep track of what the GCC
group does, I guess I owe you thanks for correcting me. If that's how one
goes abo
On Sun Apr 3 12:27:29 EDT 2011, skip.tavakkol...@gmail.com wrote:
> Why can't we use linuxemu to run the build?
>
sure we could, but then you have to maintain linuxemu, and
go. that seems silly.
> Does -fplan9-extensions not do that? Its in the latest gcc for gccgo...
what does gcc have to d
Does -fplan9-extensions not do that? Its in the latest gcc for gccgo...
On Apr 3, 2011 11:26 AM, "Lucio De Re" wrote:
> On Sun, Apr 03, 2011 at 06:34:28AM -0400, erik quanstrom wrote:
>>
>> but there definately are some difficult bits. this hacked
>> inclusion of stdio.h is a problem on plan 9.
>>
On Sun, Apr 03, 2011 at 07:49:06PM +0300, Pavel Zholkover wrote:
> What about the old gcc3 port? Is it enough for bootstrapping the compilers?
> On Apr 3, 2011 7:28 PM, "Skip Tavakkolian"
> wrote:
You'd perpetuate an alien binary format, which sounds like a bad idea
to me. But I'm so muddled up
What about the old gcc3 port? Is it enough for bootstrapping the compilers?
On Apr 3, 2011 7:28 PM, "Skip Tavakkolian"
wrote:
Why can't we use linuxemu to run the build?
-Skip
On Apr 3, 2011, at 8:43 AM, erik quanstrom wrote:
>> As GNU says, GNU is not Unix (or Plan 9). There is no #ifdef-free
>> way to satisfy both toolchains unless one wants to pervert the Plan 9
>> toolchain. One trivial change to GCC, namely Pla
> As GNU says, GNU is not Unix (or Plan 9). There is no #ifdef-free
> way to satisfy both toolchains unless one wants to pervert the Plan 9
> toolchain. One trivial change to GCC, namely Plan 9's use of empty names
> to represent unused arguments, would improve GCC greatly, but is unlikely
> to b
On Sun, Apr 03, 2011 at 06:34:28AM -0400, erik quanstrom wrote:
>
> a real solution would be one of
> 0 copy u.h; hack to taste
> 1 add the hacks to the real u.h
> 2 come to a concensus with go about what the defined-bit-width
> types should be called. change both plan 9 and go to conform.
>
On Sun, Apr 03, 2011 at 06:34:28AM -0400, erik quanstrom wrote:
>
> but there definately are some difficult bits. this hacked
> inclusion of stdio.h is a problem on plan 9.
>
> http://code.google.com/p/go-plan9/source/diff?spec=svnd6ec95bd4f9b2e9af2d10f08d9869aa2ca49d851&r=d6ec95bd4f9b2e9af2d10f
On Sat, Apr 02, 2011 at 07:48:14PM -0700, Rob Pike wrote:
>
> We'll get the Plan 9 implementation up to scratch. It's not there yet,
> though. Once things look solid we'll need a volunteer to set up a
> builder so we can automatically make sure the Plan 9 port stays
> current.
>
That's code for
> Could you comment on your changes at http://code.google.com/p/go-plan9/ ?
> Can they be pushed to mainline ?
i don't think they can in total. we should push the silly
print format fixes and the added USED() that 8c caught
and gcc didn't.
but there definately are some difficult bits. this hack
On Apr 3, 2011 12:18 PM, "erik quanstrom" wrote:
> okay, i volunteer. just to make sure, we're talking
> about a plan 9 port, not a cross compile?
>
> just let me know what i need to get set up. i can
> easily do 386 and arm at this point.
>
> - erik
>
I think Rob meant it would be a cross compi
On Sat Apr 2 22:49:25 EDT 2011, robp...@gmail.com wrote:
> We'll get the Plan 9 implementation up to scratch. It's not there yet,
> though. Once things look solid we'll need a volunteer to set up a
> builder so we can automatically make sure the Plan 9 port stays
> current.
okay, i volunteer. j
On Sun, Apr 3, 2011 at 2:52 AM, David Leimbach wrote:
> So wait... We can get the toolchain built on plan 9. Or we can target plan 9
> via cross compiler? Either way is pretty awesome! Nice work!
We are cross-compiling unless someone syncs
http://code.google.com/p/go-plan9/ with mainline.
Pav
my paatch is not correct. i've "fixed" it here, but i'd love to be
able to get a gotest binary to run on plan9 to make sure my fix is
right.
On Sun, Apr 3, 2011 at 1:45 AM, Pavel Zholkover wrote:
> I've set up a Mercurial patch queue with some instructions on building
> at https://bitbucket.org/p
I've set up a Mercurial patch queue with some instructions on building
at https://bitbucket.org/paulzhol/golang-plan9-runtime-patches/
with Andrey and Taru's patches. I'll try to keep it updated :)
Pavel
We'll get the Plan 9 implementation up to scratch. It's not there yet,
though. Once things look solid we'll need a volunteer to set up a
builder so we can automatically make sure the Plan 9 port stays
current.
-rob
Thank you!
FYI, I'm building on Ubungo 10.10, I'm getting several packages that
aren't building (io/ioutil, tabwriter, time - so far); most seem to be
lack of or conflict in definitions in os.* and syscall.*. Is this
expected?
This just gave me more ammunition to convince some Seattle Gophers
tha
http://codereview.appspot.com/4316054
:)
Things went badly here:
8g -o _go_.8 exp.go normal.go rand.go rng.go zipf.go
gopack grc _obj/hash/crc32.a _go_.8
match.go:45: undefined: Separator
match.go:62: undefined: Separator
match.go:160: undefined: Separator
match.go:227: undefined: Separator
path.go:18: undefined: Separator
path.go:19: un
cross-compilation (GOOS=plan9, GOARCH=386, link with -s), but there
are a few issues -- the build fails at crypto, so fmt is not compiled.
for a hello world you need to manually make install pkg/strconv and
pkg/reflect and pkg/fmt.
On Sat, Apr 2, 2011 at 5:04 PM, ron minnich wrote:
> On Sat, Apr 2, 2011 at 4:52 PM, David Leimbach wrote:
>> So wait... We can get the toolchain built on plan 9. Or we can target plan 9
>> via cross compiler? Either way is pretty awesome! Nice work!
>
> I'm trying a cross-build now
i.e. I se
On Sat, Apr 2, 2011 at 4:52 PM, David Leimbach wrote:
> So wait... We can get the toolchain built on plan 9. Or we can target plan 9
> via cross compiler? Either way is pretty awesome! Nice work!
I'm trying a cross-build now
ron
So wait... We can get the toolchain built on plan 9. Or we can target plan 9
via cross compiler? Either way is pretty awesome! Nice work!
Sent from my iPhone
On Apr 2, 2011, at 4:00 PM, andrey mirtchovski wrote:
> Congratulations on the hard work and thanks for seeing this through!
>
Congratulations on the hard work and thanks for seeing this through!
Hi all!
Rob just committed my syscall and os Plan 9 patches into mainline.
The produced binaries do not run properly on 9vx since the last gc changes
so its native or kvm+qemu etc.
Please test :)
Pavel
I have fixed the subject. Go is not an acronym.
2010/1/10 erik quanstrom :
>> I believe that Bell Labs are actively involved in the port of GO to
>> Plan 9, I'm not sure how much my efforts are likely to contribute to
>> that particular project.
>
> could anyone confirm this?
Sape mentioned either on go-nuts on on 9fans at some point in the pas
> I believe that Bell Labs are actively involved in the port of GO to
> Plan 9, I'm not sure how much my efforts are likely to contribute to
> that particular project.
could anyone confirm this?
- erik
Maybe this is a premature announcement, but for those who want to know
I have successfully compiled a small "Hello, world" C program for Plan
9/386 using the released GO toolchain with a number of adjustments.
The procedure I followed was along these lines:
1. Compile the release toolchain u
87 matches
Mail list logo
