Comment 1:

�please report this to your packager. This is not a Go problem.
The reason is that they didn't properly set timestamp for installed .a versus the
source code.
for example, the go command will try to build errors.a when one of its source file is
newer
than the package file (go/src/pkg/error/*.go).
I know this might be hard to get right, but perhaps take a look at what other packagers
do (for example, search for godeb)

Status changed to Invalid.

Comment 2 by schwehr:

I am one of the fink packagers!  I need help from the go team to understand how go
expects to build its world.
This is most definitely a go team question.  Please reopen this question and read
through my report.
I'm trying to make go work properly in our fink environment.  I want to figure out why
go is trying to write into the go tree when a user (which happens to be me) tries to do
hello world.    I believe we have either setup go incorrectly or go is doing the wrong
thing.
- So we just use the go build system and expect the tree that it builds to work (which
it doesn't).
- I don't see why it is okay for go to ever jump into its own tree and start changing
things (outside of the initial build / install process).  I would argue that go should
be throwing an error saying that the timestamp is bad in its package and that its env is
bad rather than the errors that I see.
- Looking at https://launchpad.net/godeb, I have no idea what you are referring me to. 
or https://github.com/mkrautz/godeb makes no sense to me either.  Can you be a little
more explicit?
Sorry if I'm missing something obvious, but go is not behaving like a typical package.

Comment 3:

sorry for closing the bug with Invalid status, but I'm pretty pretty sure the issue
is not Go's. (you can search the issue tracker for past issues like this)
as explained in #1, if you keep the relative timestamps right, Go won't ever try to
write to $GOROOT/pkg. Please double-check the timestamp, esp. pay attentions
to symlinks. (You can try install the official binary distribution and see if you
can reproduce the bug.)
by godeb, i'm referring to the one on launchpad that translates official go release
tarballs on the fly to deb package for installation.
No, Go is not a typical package, because it's a self-contained programming
environment.

Comment 4 by schwehr:

Comment by minux... should have been on this issue, not 6959, so here it is:
"""Go 1.1 series isn't supported anymore (e.g. we won't release Go 1.1.3),
The latest release (Go 1.2) does point to doc/install-source.html in $GOROOT/README."""
I will switch to 1.2 and debug from there.

Comment 5 by schwehr:

I was able to get it working with go 1.2, and I added -p to the copy commands since go
provides no install capability from its build system.
dpkg -L go | xargs ls -ld | egrep 'lrwx|(errors|math)\.(go|a)' 
lrwxr-xr-x     1 root  admin        16 Dec 15 15:49 /sw/bin/go -> ../lib/go/bin/go
lrwxr-xr-x     1 root  admin        19 Dec 15 15:49 /sw/bin/gofmt ->
../lib/go/bin/gofmt
lrwxr-xr-x     1 root  admin        22 Dec 15 15:49 /sw/lib/go/doc ->
../../share/doc/go/doc
-rw-r--r--     1 root  admin      7388 Dec 15 15:43 /sw/lib/go/pkg/darwin_amd64/errors.a
-rw-r--r--     1 root  admin    220608 Dec 15 15:43 /sw/lib/go/pkg/darwin_amd64/math.a
-rw-r--r--     1 root  admin      8330 Dec 15 15:45
/sw/lib/go/pkg/darwin_amd64_race/errors.a
-rw-r--r--     1 root  admin    270750 Dec 15 15:45
/sw/lib/go/pkg/darwin_amd64_race/math.a
-rw-r--r--     1 root  admin       499 Nov 28 13:38 /sw/lib/go/src/pkg/errors/errors.go
-rw-r--r--     1 root  admin      3081 Nov 28 13:38
/sw/lib/go/src/pkg/go/scanner/errors.go
cd ~/go
export GOPATH=`pwd`
mkdir bin
export PATH=$PATH:`pwd`/bin
go build github.com/$USER/hello
ls -ltr
./hello # that's odd, but then again, where else would it put it?
 go install github.com/$USER/hello
./bin/hello 
# Hello, world
ls -lh bin/hello 
-rwxr-xr-x  1 schwehr  5000   2.1M Dec 15 15:52 bin/hello
otool -L bin/hello 
bin/hello:
# ^ that is really weird!   Absolutely no shared libs?
strings bin/hello | tail
hash<string,float64>
*hash<string,float64>
runtime.sudog
runtime.sudog
*runtime.sudog
runtime.waitq
runtime.waitq
runtime.hchan
runtime.hchan
/sw/lib/go/src/pkg/runtime/runtime-gdb.py
# Okay, now I'm entertained that there is python running around, but worried that it's
nowhere in the stall notes that I need to make sure python is properly hooked up.

Comment 6:

You really don't want to be copying stuff out of the goroot to "install" Go. (that's why
there is no "install step")
The entire goroot should be present in the final install location.
Just untar the source to the target location and run make.bash there. Set the PATH
environment variable and you're done.

Comment 7:

Python is only necessary to use the Go gdb extensions.
You do not need Python to use the Go tool chain.
Go binaries are statically linked, hence not the shared libs.
Although most Go binaries do dynamically link against glibc.

Comment 8 by schwehr:

to: a...@golang.org  on comment #6   ARG!!!!  There really should be a top level INSTALL
file that states this very explicitly.  But think about how a deb works... you build a
tree in a jail, get it all set up, then you make a snapshot of that, then you install
that.  So it really is an important concept for many of us.
As for python, surprise undeclared dependencies cause undeclared later surprise suckage.
 :(  
Dependencies (even if rarely used) should be stated right up front and let us, who know
our systems, set (and test) these things so that they might have a chance of working.

Comment 9:

Again, Python is not a dependency of the Go tool chain. 
If you're building deb files, use launchpad.net/godeb. If you're not using godeb then
you're just duplicating work that somebody else has already done. In general, it is a
good idea to get someone who knows Go to package Go. Godeb was written by someone who
knows Go. Please use godeb if possible.
The installation instructions for Go are very clear. README points to those source
install docs. The README file is 32 lines long, and the second paragraph (after a one
line paragraph) explains how to find the install docs. Is that really so difficult?

Comment 10 by schwehr:

That's fine.  I'm not going to put any more effort into go.  I was excited for go in my
Google I/O demo with Francesc and others, but I'm not thrilled about this kind of
packaging or response to serious requests to make things work well.
I can not use godeb.  This is the fink packaging system that uses apt-get, but is NOT
debian.  Go is seriously frustrating to someone like me not because of the language, but
because the build system and documentation is totally odd ball.  That's okay, but you
have to acknowledge that other people have other ways of doing things.  If you dismiss
that, you dismiss those people from wanting to check out the language.
Thanks for pushing every one who uses the fink packager manager away from go.  I was
just trying to address real issues in the build system for go.  If you don't listen to
people who are actually reading your documentation & code and inspecting binaries, then
that's a serious downer.

Comment 11:

I have spoken to schwehr off list. He's going to take a break from this for now and
possibly re-visit packaging Go for Fink another time.

Comment 12:

even you can't use Go, Debian has its own deb packaging that build from
source, you probably can take a look how they build it.
What seems a contradiction to me is that you said we must "acknowledge
that other people have other ways of doing things", but you failed to apply
that principle to Go itself. Why? Go has Go way of doing things.
You said you're trying to help to make Go better, I certainly appreciate that.
However, all issues that you filed are not valid for one reason or another.
For this particular issue, as I explained several times, the Go command will try
to determine the relative timestamp of source and *.a files, and only rebuild
the later when necessary. If you don't preserve the timestamp when installing
Go (I know a lot of package management software mess with timestamps, so
you're not alone), Go will try to rebuilt all standard library. That's not a Go
bug in any way.
The official way to install Go on OS X is either building from source, use the
officially signed pkg installer files.