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
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
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 -p
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
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 sergey.k...@gmail.com wrote:
Hello,
I'm unable to make go plan9 crosscompiler.
Can you help me?
# I use patched repo
hg qclone
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
Great info! thanks.
-Skip
On Sat, Apr 9, 2011 at 11:53 AM, Pavel Zholkover paulz...@gmail.com 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
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
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 with
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:
Sent from my iPhone
On Apr 6, 2011, at 1:27 PM, Joel C. Salomon joelcsalo...@gmail.com 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 5, 2011 at 7:33 AM, Lucio De Re lu...@proxima.alt.za 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
Anthony Martin al...@pbrane.org once said:
-#define MaxArena32 (2U30)
+#define MaxArena32 (240U20)
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
On Mon, Apr 4, 2011 at 10:11 PM, Russ Cox r...@swtch.com wrote:
The best answer might be to make USTKTOP 1GB.
Agreed.
ron
On Mon, Apr 4, 2011 at 9:22 PM, Russ Cox r...@swtch.com 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.
On Mon, Apr 4, 2011 at 10:11 PM, Russ Cox r...@swtch.com 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
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 Tue, Apr 5, 2011 at 10:36 AM, erik quanstrom quans...@labs.coraid.comwrote:
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
InfernGo?
Goribund ;)
2011/4/5 andrey mirtchovski mirtchov...@gmail.com
InfernGo?
Goribund ;)
What a positive sounding project name!
2011/4/5 Lucio De Re lu...@proxima.alt.za:
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
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 yari...@gmail.com wrote:
2011/4/5 Lucio De Re lu...@proxima.alt.za:
As for not running Go on 9vx, that's a pain, I have such a nice 9vx
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 al...@pbrane.org wrote:
Pavel Zholkover paulz...@gmail.com once said:
I'm not sure I
On Sun, Apr 3, 2011 at 2:24 PM, erik quanstrom quans...@labs.coraid.com 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
On Mon Apr 4 11:19:37 EDT 2011, rminn...@gmail.com wrote:
On Sun, Apr 3, 2011 at 2:24 PM, erik quanstrom quans...@labs.coraid.com
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,
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 run
On Mon, Apr 4, 2011 at 8:27 PM, Lucio De Re lu...@proxima.alt.za 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
[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
of
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 lu...@proxima.alt.za 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
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 4, 2011 at 8:59 AM, erik quanstrom quans...@quanstro.net 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
On Mon, Apr 4, 2011 at 10:27 AM, Lucio De Re lu...@proxima.alt.za 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 :-)
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, Go
well, Russ has blessed the runtime fix :-)
I look forward to having go in 9vx too!
ron
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
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 04, 2011 at 04:10:15PM -0700, ron minnich wrote:
On Mon, Apr 4, 2011 at 10:27 AM, Lucio De Re lu...@proxima.alt.za 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
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, if
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 convincing
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
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
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 fix it to
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
On Sun, Apr 3, 2011 at 2:52 AM, David Leimbach leim...@gmail.com 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/
On Apr 3, 2011 12:18 PM, erik quanstrom quans...@quanstro.net 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
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
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 we'll
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 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.
i'd
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 be
Why can't we use linuxemu to run the build?
-Skip
On Apr 3, 2011, at 8:43 AM, erik quanstrom quans...@quanstro.net 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
What about the old gcc3 port? Is it enough for bootstrapping the compilers?
On Apr 3, 2011 7:28 PM, Skip Tavakkolian skip.tavakkol...@gmail.com
wrote:
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 skip.tavakkol...@gmail.com
wrote:
You'd perpetuate an alien binary format, which sounds like a bad idea
to me.
Does -fplan9-extensions not do that? Its in the latest gcc for gccgo...
On Apr 3, 2011 11:26 AM, Lucio De Re lu...@proxima.alt.za 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 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 do
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
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
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
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
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
andrey mirtchovski mirtchov...@gmail.com 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.
Anthony Martin al...@pbrane.org 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.
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
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
Pavel Zholkover paulz...@gmail.com 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
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
Congratulations on the hard work and thanks for seeing this through!
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 mirtchov...@gmail.com wrote:
Congratulations on the hard work and thanks for seeing
On Sat, Apr 2, 2011 at 4:52 PM, David Leimbach leim...@gmail.com 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
On Sat, Apr 2, 2011 at 5:04 PM, ron minnich rminn...@gmail.com wrote:
On Sat, Apr 2, 2011 at 4:52 PM, David Leimbach leim...@gmail.com 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
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.
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:
http://codereview.appspot.com/4316054
:)
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
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
2010/1/10 erik quanstrom quans...@quanstro.net:
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
I have fixed the subject. Go is not an acronym.
77 matches
Mail list logo
