[9fans] Building Go on Plan 9

Anthony Martin

unread,

Dec 1, 2011, 12:48:58 PM12/1/11

to

A few people were asking about this so I
wrote up a tutorial. I also uploaded a
copy to http://apm.sdf.org/go/NOTES for
anyone who has trouble with attachments.

Cheers,
Anthony

NOTES

John Floren

unread,

Dec 1, 2011, 1:00:24 PM12/1/11

to

How many different Go porting efforts do we now have for Plan 9?
There's apparently yours, Ron's, Lucio's, and I think the 9front guys
have/had something cooking too.

Which ones can actually be updated with "hg pull"?

John

Stanley Lieber

unread,

Dec 1, 2011, 1:05:48 PM12/1/11

to

Taruti has said the 9front port is dead, pending developments with the
other ports.

-sl

Anthony Martin

unread,

Dec 1, 2011, 1:14:55 PM12/1/11

to

John Floren <jo...@jfloren.net> once said:
> How many different Go porting efforts do we now
> have for Plan 9? There's apparently yours, Ron's,
> Lucio's, and I think the 9front guys have/had
> something cooking too.

That's it as far as I know.

> Which ones can actually be updated with "hg pull"?

None yet.

I have CLs at the ready for every change
I've made and I'm committed to getting
them upstream.

Not to be presumptuous but I really think
the way I've done it is the best way forward.
All you need is GNU Make, Mercurial, a few
modified library headers and the bundle of
changes that I put in 9fix.patch.

I'd like to get the library headers in Nix
and hopefully even Plan 9 proper. Then
there's only a handful of changes that I
need to get into the Go distribution.

It will happen. :-)

Cheers,
Anthony

erik quanstrom

unread,

Dec 1, 2011, 12:51:00 PM12/1/11

to

please just post again inline because 9fans.net doesn't archive attachments.

- erik

Anthony Martin

unread,

Dec 1, 2011, 1:28:06 PM12/1/11

to

Charles Forsyth <charles...@gmail.com> once said:
> modified library headers?

% ls (386 sys)^/include/go
386/include/go/u.h
386/include/go/ureg_amd64.h
386/include/go/ureg_arm.h
386/include/go/ureg_x86.h
sys/include/go/ar.h
sys/include/go/bio.h
sys/include/go/bootexec.h
sys/include/go/goenv.h
sys/include/go/libc.h
sys/include/go/mach.h
sys/include/go/stdio.h

Some of these are just copies of the standard
headers and others have a few adjustments that
the Go toolchain requires. All except mach.h
have #pragmas that point to the stock location
in /386/lib/*.a.

Anthony

Anthony Martin

unread,

Dec 1, 2011, 1:18:37 PM12/1/11

to

erik quanstrom <quan...@quanstro.net> once said:
> please just post again inline because 9fans.net
> doesn't archive attachments.

Sure thing.

---

# Building Go on Plan 9
# Anthony Martin
# al...@pbrane.org

# This document will guide you through the process
# of compiling the commands and packages in the Go
# source code distribution.
#
# Before we get started you should make sure you
# have GNU Make installed. The version on contrib
# is 3.81 and is just fine for our purposes.
#
# It's also necessary to have Mercurial installed
# and I believe there is a version on contrib as
# well.
#
# After reading this document you can extract the
# commands and pipe them to the shell using:
#
# sed -n 's,^[% ] ,,p' NOTES | rc
#
# I highly recommend reading all the way through
# before running the commands.
#

# First we must fetch the archive that contains
# modified include files, a build script, and a
# patch consisting of all pending (and not yet
# submitted) CLs pertaining to Plan 9.

% cd /tmp
% hget http://apm.sdf.org/go/root.tbz >root.tbz

# Next we must verify the SHA1 hash of the archive.

% want = ed25980b3b813b1c80506b56331d83c4d485a4c0
% have = `{sha1sum root.tbz | awk '{print $1}'}
% if(! ~ $have $want){
echo 'ZOMG! INVALID SHA1 CHECKSUM'
echo have: $have
echo want: $want
exit badhash
}

# Now we're ready to fetch the source code for the
# Go repository hosted at Google Code. I had to
# make a decision about where this would reside so
# after a bit of thinking I chose /sys/src/go to
# mirror the structure of APE.
#
# The other important directories that will be
# created when extracting the archive are:
#
# /386/bin/go (for binaries),
# /386/include/go (for machine dependent C headers),
# /386/lib/go (for Go's C libraries),
# and
# /sys/include/go (for machine independent C headers).

% cd /sys/src
% hg clone -u 2d7711ae https://go.googlecode.com/hg/ go
requesting all changes
adding changesets
adding manifests
adding file changes
added 10641 changesets with 40432 changes to 5437 files (+4 heads)
updating to branch default
3231 files updated, 0 files merged, 0 files removed, 0 files unresolved

# After fetching the Go repository we can extract
# the archive into the file system's root. It's
# always a good idea to check the contents of an
# archive before doing something this drastic.

% cd /
% tar xvzf /tmp/root.tbz
tar: blocking = 16
386
386/bin
386/bin/go
386/include
386/include/go
386/include/go/ureg_x86.h
386/include/go/ureg_amd64.h
386/include/go/u.h
386/include/go/ureg_arm.h
386/lib
386/lib/go
sys
sys/include
sys/include/go
sys/include/go/bootexec.h
sys/include/go/mach.h
sys/include/go/ar.h
sys/include/go/bio.h
sys/include/go/stdio.h
sys/include/go/libc.h
sys/include/go/goenv.h
sys/src
sys/src/go
sys/src/go/9fix.patch
sys/src/go/src
sys/src/go/src/make.rc

# We're almost done. We can now apply the patch file
# into the root of the Go tree.

% cd /sys/src/go
% ape/patch -p1 < 9fix.patch

# Our final step is to build the commands and packages.
# Running make.rc will produce tons of output so you
# might want to redirect it to a file.

% cd src
% ./make.rc

# Now that you have a working build of Go you
# should help me make sure all of the tests pass. :-)
# Email me if you're interested in helping out.
#
# In other news, I'm working on setting up an
# an automated builder so we can include Plan 9
# in the Go Dashboard.
#
# Also, please don't submit any of the changes in
# the patch file to the Go development list. Most
# of the changes have corresponding CLs and the few
# others are still being pondered.
#
# That's all for now. Have fun!

unread,

Dec 1, 2011, 1:48:23 PM12/1/11

to

Anthony Martin <al...@pbrane.org> once said:
> You would think so but that's how
> where the headers are expected to
> be for Go's libmach.

"how where"?

I shouldn't type when tired.

Anthony

Lyndon Nerenberg

unread,

Dec 1, 2011, 1:25:56 PM12/1/11

to

> modified library headers?

I stopped at gmake. What can't mk do that demands gmake?

Anthony Martin

unread,

Dec 1, 2011, 2:07:24 PM12/1/11

to

Lyndon Nerenberg <lyn...@orthanc.ca> once said:
> I stopped at gmake. What can't mk do that demands gmake?

There's nothing wrong with mk. It's just that
I highly doubt we could get a separate set of
mkfiles included in the Go distribution.

I've tried to get things going with the smallest
set of changes to both Plan 9 and Go and I think
using GNU Make is the only way to do that.

Anthony

Lyndon Nerenberg

unread,

Dec 1, 2011, 2:54:03 PM12/1/11

to

> There's nothing wrong with mk. It's just that
> I highly doubt we could get a separate set of
> mkfiles included in the Go distribution.

Have you tried? It's a non-invasive change, and once they are set up it's
unlikely they will need to be updated often.

lsub

unread,

Dec 1, 2011, 2:20:38 PM12/1/11

to

send a change to nix-dev to include the se headers.
the process file describes how to do it.

Another alternative is to make a contrib package for nix
that could be installed with pm.

Perhaps that's a better option.

--
using ipad keyboard. excuse any typos.

> [/mail/box/nemo/msgs/201112/50]

Lucio De Re

unread,

Dec 1, 2011, 10:39:13 PM12/1/11

to

I think Anthony is on the right path on this point, in that I've had
to update a couple of mkfiles in the recent past because I had
overlooked changes to the coresponding Makefiles. Not many, but they
do trigger additional maintenance problems.

The only alternative option I would pick is to merge the Go release
into the Plan 9 (and nix) distribution - mkfiles and all - then use a
mechanism analogous to mine to keep them in sync. The unsuspecting
public would never see the hard backroom effort.

In my fantasies, I see p9p as a stepping stone in that direction.

Lastly, my congratulations to Anthony, if there is any way I can
assist in merging the code, I'd be happy to help (just don't ask me to
install Python and Mercurial on my Plan 9 system - mind you, I'll
probably have to do so, sooner or later :-(.

Lucio.

ron minnich

unread,

Dec 2, 2011, 1:34:22 AM12/2/11

to

I've tried. The answer is "no". No mkfiles in the tree. I've not
watched this thread. Is this another totally different approach?

ron

Lucio De Re

unread,

Dec 2, 2011, 1:42:02 AM12/2/11

to

> I've tried. The answer is "no". No mkfiles in the tree. I've not
> watched this thread. Is this another totally different approach?

My understanding is that Anthony Martin is working on an APE angle.
If using APE suffices, I'm in favour of it, but I'm reserving
judgement until the issue is cleared. I do expect complications, but
I'm sure they can be surmounted.

For my part, I prefer a mkfile approach that can be tracked by Bell
Labs and included in the official distribution. I would be interested
in the approach Nemo might choose for nix.

++L

Francisco J Ballesteros

unread,

Dec 2, 2011, 3:49:59 AM12/2/11

to

Well, that's actually the approach Ron would choose for nix.
IIRC, there were a bunch of mkfiles added to the std. go tree
to make it compile, but I may be mistaken.
Ron knows better.

Anthony Martin

unread,

Dec 2, 2011, 9:33:11 AM12/2/11

to

Lucio De Re <lu...@proxima.alt.za> once said:
> > Have you tried? It's a non-invasive change, and once they are set
> > up it's unlikely they will need to be updated often.
>
> I think Anthony is on the right path on this point, in that I've had
> to update a couple of mkfiles in the recent past because I had
> overlooked changes to the coresponding Makefiles. Not many, but they
> do trigger additional maintenance problems.
>
> The only alternative option I would pick is to merge the Go release
> into the Plan 9 (and nix) distribution - mkfiles and all - then use a
> mechanism analogous to mine to keep them in sync. The unsuspecting
> public would never see the hard backroom effort.

IMO using anything other than Make to build
the Go distribution is a fool's errand and
simply too much of a maintenance burden.
We would have to carefully watch upstream
changes to any of the many Makefiles.

Using make isn't as bad as some make it out
to be and, to be clear, I'm only advocating
the use of make to build the distribution;
we can still add rules for building tools
or libraries written in Go to the standard
mkfiles in /sys/src.

Anthony

P.S.
I plan to switch from GNU Make to APE make
once I have the time to look closely at the
Go Makefiles for any GNU specific features
and then make the necessary changes or even
modify ape/make.

unread,

Dec 2, 2011, 11:09:31 AM12/2/11

to

> I have had the most recent version of Gmake running as the APE tool of
> choice, but I seem to have misplaced it. Still, no need to treat
> Gmake and ape/make as different, they should be close enough for all
> intents and purposes.
>
> In fact, compiling Gmake itself is not much of a mission, unlike bison.

This is what I found:

term% 8.out -v
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for Plan 9/386

I'm not sure if there is a later version, it's been a long time since I looked.

++L

Skip Tavakkolian

unread,

Dec 2, 2011, 12:14:56 PM12/2/11

to

i think having Go is worth dealing with the beast.

ron minnich

unread,

Dec 2, 2011, 12:21:06 PM12/2/11

to

On Fri, Dec 2, 2011 at 12:49 AM, Francisco J Ballesteros <ne...@lsub.org> wrote:
> Well, that's actually the approach Ron would choose for nix.
> IIRC, there were a bunch of mkfiles added to the std. go tree
> to make it compile, but I may be mistaken.
> Ron knows better.

My first hope was pretty much what others have said here: parallel
mkfiles to the Makefiles, because I expected they would change slowly
if at all. Andrey and I did get this going, and a simple
mk install
in go/src
sufficed to build and install all Go packages and produce some working
binaries, however that approach is not going to be accepted, because
it requires mkfiles in the Go source tree.

For the record, it takes a surprisingly small amount of effort to make
this work, once you know what is going on. Oh, and, there are some
bugs in the Go source that are uncovered when one builds on NIX. I've
submitted one fix and have one or two more in the works. The work has
not been in vain.

I think we need to be realistic about how much we can influence the Go
mainline source. I keep seeing comments on 9fans about how we can
change the way the Go source is written/built/managed, and those
comments envision some signiifcant changes. To repeat, I have been
told in no uncertain terms that changing the way Go is set up to
accommodate great Plan 9 ideas is just not going to happen, and that
our "footprint" in the Go source tree must remain very small. I think
that is the correct approach on the part of the Go team.

We have made minor changes on NIX to accomodate Go. Simple examples:
/*/mkfile
have an entry for the name of the Go compiler. There is a /go directory.

Based on the Python experience, where Plan 9's python is always far
behind the leading edge, I still believe that it is best if the
following always worked:

hg clone the-official-go-tree go
cd go/src
./some-shell-script

I do not think it makes sense to have Go source distributed as part of
the Plan 9 distro or contrib mechanism as that approach has not worked
well (in my view) for Python. Again, what I'd like to have is a Go
that always builds on Plan 9 from the mainline go source tree,
without having to dump in lots of patch files and other junk or change
the Makefiles. Andrey and I worked toward a "build with zero changes"
model. We did not get done and decided to wait for Go 1 anyway because
the number of Makefiles will be greatly reduced in Go 1 -- I expect
there will be less than 10 or so.

I believe the Go authors will accept a single shell script or two and
a go/9/include tree as part of the standard distro, so we need to
think in those terms. What I have in go/9/include today are some u.h
files, and that and a very simple set of changes should suffice to let
us build Go on Plan 9 with *zero* changes from the standard go source.

I hope that last paragraph was not too confusing.

Thanks

ron

ron minnich

unread,

Dec 2, 2011, 12:24:59 PM12/2/11

to

On Fri, Dec 2, 2011 at 6:33 AM, Anthony Martin <al...@pbrane.org> wrote:

> modify ape/make.

That strikes me as a good approach. The Go Makefiles do use very
standard Plan 9 like idioms but there are a few things they do that
looked gmake-dependent to me. There are very few of them however.

ron

Lyndon Nerenberg

unread,

Dec 2, 2011, 12:55:12 PM12/2/11

to

>> modify ape/make.

I was just waiting for this :-P

Please do NOT fuck with ape/make. As the paper says, APE has become more
of a tool to write conforming ANSI / POSIX code vs. porting the stuff to
Plan 9. Please don't take apes' virginity.

If people insist on inflicting gmake upon us, fine. I guess. But please
(please?) don't screw the ape: deposit it in /$cputype/bin/gmake instead.

And now that the camel is firmly in the tent, we might as well
create a <foo>/camel hierarchy to parallel <foo>/ape, for all the
camel cruft (i.e. /$cputype/camel/make vs. /$cputype/bin/gmake).

Then, people who want to ride camels through the desert can run bsh(1) to
obtain a suitably inhospitable environment. (bsh as in baking-hot shell,
although bs(1) seems like a reasonable alternative.)

Lyndon Nerenberg

unread,

Dec 2, 2011, 12:58:22 PM12/2/11

to

> (i.e. /$cputype/camel/make

Yes, I meant /$cputype/bin/camel/make. You get the general idea ...

unread,

Dec 2, 2011, 3:25:16 PM12/2/11

to

My freebsd-current flamewar is dying out, so time for something new ...

Why are parallel mkfiles in the /go tree considered eeevil? They seemed
to be very low overhead. Surely accomodations are being made for Windows.

Regardless, if we want native go, is it that unreasonable to maintain a
port ala spin? My fiddling with the go tree makes me think it isn't that
hard to set up an overlay that adopts the live go tree to what Plan9 needs
for a build. bind(1) is a wonderful thing -- we should use it!

The most dynamic part of the go source tree these days seems to be
pkg/Makefile (as far as a native build is concerned). It can't be that
hard to parse out DIR= from there and turn it into a native mkfile.

ron minnich

unread,

Dec 2, 2011, 3:37:45 PM12/2/11

to

nobody is stopping you from doing anything. go for it.

ron

erik quanstrom

unread,

Dec 2, 2011, 4:42:40 PM12/2/11

to

On Fri Dec 2 13:21:09 EST 2011, rmin...@gmail.com wrote:
> On Fri, Dec 2, 2011 at 9:58 AM, Francisco J Ballesteros <ne...@lsub.org> wrote:

> > +1 for using parallel mkfiles.
>

> as I say, I liked this too, but it fails the zero changes rule.

if the rule is literally "zero change", then we should give up now.

- erik

andrey mirtchovski

unread,

Dec 2, 2011, 5:12:25 PM12/2/11

to

> if the rule is literally "zero change", then we should give up now.

Russ has been most accommodating with changes in the Go tree. As far
as go portability to Plan 9 is concerned, that's not a problem (except
the few actual problems that need fixing, but that's just code). The
issue is polluting the go tree with yet another build framework which
is 1) not really necessary, 2) about to be taken out anyway and 3)
possible to devise programatically. Russ has said privately (jokingly)
that he'd accept mkfiles if each one said "|<$GOROOT/mkmk.rc Makefile"
and, knowing what we know now, it's not impossible to do.
rminnich-9go's mkfiles for the go package library were mostly created
with such a script.

more important issues exist than just how to build go (which boils
down to "pick any of the 3 current methods and go for it") -- for
example, in order to complete running the full test suite one needs to
solve a signal handling bug in the plan9-specific code of the go
runtime.

unread,

Dec 2, 2011, 7:12:51 PM12/2/11

to

Did you try it? Might be worth trying it. We did. But maybe it's time
to try things first and then send email :-)

ron

Federico Benavento

unread,

Dec 4, 2011, 7:32:05 PM12/4/11

to

On Dec 2, 2011, at 9:12 PM, ron minnich wrote:

> Did you try it? Might be worth trying it. We did. But maybe it's time
> to try things first and then send email :-)

relax, maybe he didn't, but he did write a tool that parses configure/makefiles
and generates mkfilles

John Floren

unread,

Dec 4, 2011, 7:44:44 PM12/4/11

to

What's it called? Where can I get it? Sounds pretty useful.

John

Federico Benavento

unread,

Dec 5, 2011, 7:20:44 AM12/5/11

to

mkmk

Aram Hăvărneanu

unread,

Dec 27, 2011, 9:38:45 AM12/27/11

to

Lyndon Nerenberg wrote:
> Why are parallel mkfiles in the /go tree considered eeevil? They seemed to
> be very low overhead. Surely accomodations are being made for Windows.
>

> [...] My fiddling with the go tree makes me think it isn't that hard to

> set up an overlay that adopts the live go tree to what Plan9 needs for a
> build. bind(1) is a wonderful thing -- we should use it!
>

> [...] It can't be that hard

> to parse out DIR= from there and turn it into a native mkfile.

I'm very late in the discussion, but I'd like to point out that Go is
already using the go build tool instead of makefiles, at least for
some part of the tree. I believe this simplifies things greatly. No
makefiles to maintain or generate.

--
Aram Hăvărneanu