I got following error on any Go example from http://golang.org
~/tmp/go$ go build pi.go # runtime /usr/local/go/src/pkg/runtime/extern.go:121: undefined: defaultGoroot /usr/local/go/src/pkg/runtime/extern.go:130: undefined: theVersion /usr/local/go/src/pkg/runtime/extern.go:135: undefined: theGoos /usr/local/go/src/pkg/runtime/extern.go:135: cannot use theGoos as type string in const initializer /usr/local/go/src/pkg/runtime/extern.go:139: undefined: theGoarch /usr/local/go/src/pkg/runtime/extern.go:139: cannot use theGoarch as type string in const initializer ~/tmp/go$ On 01:05 Fri 30 Mar , Joel Sing wrote: > Go 1 was released yesterday - the attached is an updated port. > > Any further comments? Any oks? > > On Monday 26 March 2012, Joel Sing wrote: > > A new version - this updates the port to the 2012-03-22 weekly release > > (effectively Go v1 RC2) and fixes the issue with the regress path for > > the "go" binary. > > > > ok? > > > > On Friday 23 March 2012, Joel Sing wrote: > > > Attached is an updated version of the port for Go: > > > > > > - Version numbering is now 1.0preYYYYMMDD as suggested by sthen. > > > > > > - Fixed PLIST issue so that the port now works correctly on both amd64 > > > and i386. > > > > > > - Fixed issue with USE_SYSTRACE - for the time being a Go binary needs to > > > be able to use the sysarch() syscall in order to setup TLS. > > > > > > ok? > > > > > > On Thursday 22 March 2012, Joel Sing wrote: > > > > The attached is an initial port for the Go programming language > > > > (www.golang.org). A little background - Go is approaching a "Go > > > > version1" release and at that point it will have a stable API. > > > > Unfortunately, for several reasons Go version 1 will not be officially > > > > supported on OpenBSD, however there are only a few issues that prevent > > > > this - the diffs included in the port address known outstanding issues > > > > for the OpenBSD runtime, which will let us provide a working port. > > > > > > > > Open questions: > > > > > > > > 1. Version numbering - in some ways once Go version 1 is release the > > > > versioning will be somewhat like Python and in the future you may want > > > > to install Go version 1 and Go version 2 on the same machine (different > > > > APIs for example). However, during the development phase there are > > > > weekly tagged releases that are simply YYYY-MM-DD versioned. For this > > > > reason I'm thinking that the version numbering should be 0.YYYYMMDD for > > > > now and 1.0 for the version 1 release. Continued development could then > > > > follow on the 0.YYYYMMDD releases. Or should we have two packages - a > > > > "go-weekly" package and a "go" package? > > > > > > > > 2. The installation locations is going to get somewhat messy - due to > > > > some of the internals of Go's design everything except a few user > > > > binaries (so documentaiton, libraries, source code, etc) needs to be > > > > under a single directory. For now I've used the "recommended" default > > > > of /usr/local/go, however this is not really acceptable for OpenBSD. > > > > Suggestions as to what would be the closest suitable location? I plan > > > > on talking with upstream re being able to split this so that we at > > > > least have tool/libexec type binaries and libraries separated out from > > > > the docs/source. > > > > > > > > 3. License - Go is released under a BSD-style license, however some > > > > parts (like the documentation) are under other licenses (Creative > > > > Commons Attribution 3.0 License). How do we handle this? > -- > > "Reason is not automatic. Those who deny it cannot be conquered by it. > Do not count on them. Leave them alone." -- Ayn Rand
