release.2010-08-25
Andrew Gerrand
can update by running:
hg pull
hg update release
This release includes changes to the build system that will likely require you
to make changes to your environment variables and Makefiles.
All environment variables are now optional:
- $GOOS and $GOARCH are now optional; their values should now be inferred
automatically by the build system,
- $GOROOT is now optional, but if you choose not to set it you must run
'gomake' instead of 'make' or 'gmake' when developing Go programs
using the conventional Makefiles,
- $GOBIN remains optional and now defaults to $GOROOT/bin;
if you wish to use this new default, make sure it is in your $PATH
and that you have removed the existing binaries from $HOME/bin.
As a result of these changes, the Go Makefiles have changed. If your Makefiles
inherit from the Go Makefiles, you must change this line:
include ../../Make.$(GOARCH)
to this:
include ../../Make.inc
This release also removes the deprecated functions in regexp and the
once package. Any code that still uses them will break.
See the notes from the last release for details:
http://golang.org/doc/devel/release.html#2010-08-11
Other changes:
* 6g: better registerization for slices, strings, interface values
* 6l: line number information in DWARF format
* build: $GOBIN defaults to $GOROOT/bin,
no required environment variables
* cgo: add C.GoStringN (thanks Eric Clark).
* codereview: fix issues with leading tabs in CL descriptions,
do not send "Abandoned" mail if the CL has not been mailed.
* crypto/ocsp: add missing Makefile.
* crypto/tls: client certificate support (thanks Mikkel Krautz).
* doc: update gccgo information for recent changes.
fix errors in Effective Go.
* fmt/print: give %p priority, analogous to %T,
honor Formatter in Print, Println.
* gc: fix parenthesization check.
* go/ast: facility for printing AST nodes,
first step towards augmenting AST with full type information.
* go/printer: do not modify tabwriter.Escape'd text.
* gofmt: do not modify multi-line string literals,
print AST nodes by setting -ast flag.
* http: fix typo in http.Request documentation (thanks Scott Lawrence)
parse query string always, not just in GET
* image/png: support 16-bit color.
* io: ReadAtLeast now errors if min > len(buf).
* jsonrpc: use `error: null` for success, not `error: ""`.
* libmach: implement register fetch for 32-bit x86 kernel.
* net: make IPv6 String method standards-compliant (thanks Mikio Hara).
* os: FileInfo.Permission() now returns uint32 (thanks Scott Lawrence),
implement env using native Windows API (thanks Alex Brainman).
* reflect: allow PtrValue.PointTo(nil).
* runtime: correct line numbers for .goc files,
fix another stack split bug,
fix freebsd/386 mmap.
* syscall: regenerate syscall/z* files for linux/386, linux/amd64, linux/arm.
* tabwriter: Introduce a new flag StripEscape.
* template: fix handling of space around actions,
vars preceded by white space parse correctly (thanks Roger Peppe).
* test: add test case that crashes gccgo.
* time: parse no longer requires minutes for time zone (thanks Jan H. Hosang)
* yacc: fix bounds check in error recovery.
To see a full list of changes between this and the previous release,
after updating, run:
hg log -r release.2010-08-11:release.2010-08-25
Enjoy.
Andrew
abiosoft
David Roundy
> what is now the default $GOROOT?
I think the point is that GOROOT is whatever directory in which you
build go. If you want to safely determine GOROOT, you now need to use
gomake (although there may be another trick that I'm not aware of).
It'd be nice if 6l had an option to query the package search path,
which would provide much the same information.
David
Russ Cox
<rou...@physics.oregonstate.edu> wrote:
> On Wed, Aug 25, 2010 at 10:42 AM, abiosoft <abio...@gmail.com> wrote:
>> what is now the default $GOROOT?
>
> I think the point is that GOROOT is whatever directory in which you
> build go.
Correct.
> If you want to safely determine GOROOT, you now need to use
> gomake (although there may be another trick that I'm not aware of).
> It'd be nice if 6l had an option to query the package search path,
> which would provide much the same information.
That seems like a roundabout way to obtain GOROOT,
especially since people who built for 386 wouldn't
even have a 6l. In practice I think that people who
want to do serious Go development are still best served
by setting $GOROOT. But if you're just starting out
you don't have to, which avoids a hurdle.
Russ
Risto Saarelma
using packages. This breaks things for packages whose sources aren't
in $GOROOT/src/something.
I can fix this by symlinking $GOROOT/src/cmd/cgo in the appropriate
cmd subdirectory in my local project directory, but that's a bit ugly.
Russ Cox
[This is not about the release. If you "hg update release" you
should have no trouble, since this change was made after the
most recent release.]
deps.bash was never intended to be a general purpose program.
It's a program meant to run in $GOROOT/src/pkg. If you want
to use it in some other context, it doesn't seem unreasonable
that you'd have to adapt it.
Russ
⚛
j2" is passes to make. Here's an informal description of the problem:
$ cat Makefile
include $(GOROOT)/src/Make.inc
TARG=x
CGOFILES:=x.go
include $(GOROOT)/src/Make.pkg
$ make --version
GNU Make 3.81
$ make -j1
CGOPKGPATH= cgo -- x.go
8c ... _cgo_defun.c
$ make -j2
CGOPKGPATH= cgo -- x.go
CGOPKGPATH= cgo -- x.go
8c ... _cgo_defun.c
The first obvious difference is that there are two cgo commands being
executed. In addition, make will execute the two cgo commands in
*parallel*. Also, 8c is sometimes started *before* completing both of
the cgo commands, which results in random compilation failures because
the file _cgo_defun.c has incomplete contents at the moment.
I suppose this is a GNU make bug.
⚛
I suppose it is caused by the Make.pkg rule that has multiple targets.
The section "4.10 Multiple Targets in a Rule" from "info make" says
that
a b: c
CMD
is equivalent to
a: c
CMD
b: c
CMD
Russ Cox
⚛
Note: There is a stray space at the beginning of the line with
"@true".
On Aug 26, 5:29 pm, Russ Cox <r...@golang.org> wrote:
> Thanks for the diagnosis.
> Doeshttp://codereview.appspot.com/2007047
Peter Bourgon
After upgrading, one of my projects is failing to build with messages like:
inconsistent definition for type reflect.FuncType during import
struct { reflect.commonType "func"; dotdotdot bool; in
[]*runtime.Type; out []*runtime.Type }
struct { reflect.commonType; dotdotdot bool; in []*runtime.Type; out
[]*runtime.Type }
inconsistent definition for type reflect.FuncType during import
struct { reflect.commonType "func"; dotdotdot bool; in
[]*runtime.Type; out []*runtime.Type }
struct { reflect.commonType; dotdotdot bool; in []*runtime.Type; out
[]*runtime.Type }
The import line triggering these errors is for web.go. I suspect there
is some leftover cruft somewhere, but I'm not sure how to blast it
away. Any thoughts?
nsf
Just try to rebuild all libraries (.a files) that are a part of the app
you are building. It's caused by the fact that one of the .a files was
compiled using previous compiler version.
Adrian
Has anyone run into this problem?
After taking the usual steps to update to the latest release (hg pull;
hg update release in the src directory), I ran all.bash there and keep
getting:
--- cd ../doc/progs
file.go:66: cannot convert e (type int) to type os.Error:
int does not implement os.Error (missing String method)
file.go:66: invalid operation: ((node XXX)) != 0 (type os.Error !=
int)
I removed all GO env vars, except for GOROOT.
I am running this on: Linux 2.6.32-24-generic-pae #41-Ubuntu SMP Thu
Aug 19 02:43:57 UTC 2010 GNU/Linux
How can I get past this? Can I do make a clean or something?
Thanks.
Adrian
Changed line 66 of doc/progs/file.go from
if os.Error(e) != 0 {
to
if e != 0 {
and that fixes it.
Am surprised that I am the only one to have come across this.
peterGo
> Changed line 66 of doc/progs/file.go from
>
> if os.Error(e) != 0 {
>
> to
>
> if e != 0 {
if os.Error(e) != 0 {
http://code.google.com/p/go/source/browse/doc/progs/file.go
I've never encountered your problem.
Peter
Adrian
Well then, maybe it was a merge/update problem?
Surely it wasn't put in there by me - I didn't even know of the file's
existence before I encountered the error.