Phrases like "returns whether or not the image is opaque" could be
describing what the function does (it always returns, regardless of
the opacity) or what it returns (a boolean indicating the opacity).
Even when the "or not" is missing, the phrasing is bizarre.
Go with "reports whether", which is still clunky but at least makes
it clear we're talking about the return value.
These were edited by hand. A few were cleaned up in other ways.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/11699043
This does not change the default compiler on OS X to clang.
It appears that for now we can keep using gcc as long as we
enable a few more warning settings that are on-by-default
elsewhere.
R=golang-dev, bradfitz, dave
CC=golang-dev
https://golang.org/cl/11610044
Change build system to set GO_EXTLINK_ENABLED=0 by default for
OS X 10.6, since the system linker has a bug and can not
handle the object files generated by 6l.
Fixes#5130.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/8183043
1. when executing a unsupported VFP instruction, the NetBSD kernel somehow
doesn't report SIGILL, and instead just spin and spin, we add a alarm(2)
to detect this case (albeit this is a kernel bug).
2. NetBSD/ARM's VFP11 support is not complete, so temporarily disable it.
3. The default gcc shipped with NetBSD-current mis-optimizes our code
at -O2, so lower the optimization level to -O1 on NetBSD/ARM.
R=dave, rsc
CC=golang-dev
https://golang.org/cl/7286044
Or gcc (-fPIC) will complain:
cmd/dist/unix.c: In function ‘cansse2’
cmd/dist/unix.c:774: error: can't find a register in class ‘BREG’ while reloading ‘asm’
cmd/dist/unix.c:774: error: ‘asm’ operand has impossible constraints
This affects bootstrapping on native Darwin/386 where all code is
compiled with -fPIC.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/7394047
sse2 is a more precise description of the requirement,
and it matches what people will see in, for example
grep sse2 /proc/cpuinfo # linux
sysctl hw.optional.sse2 # os x
R=golang-dev, dsymonds, iant
CC=golang-dev
https://golang.org/cl/7057050
The debian/kFreeBSD project uses the FreeBSD kernel and the debian userspace. From our point of view, this is freebsd not linux as GOOS talks about the kernel syscall interface, not the userspace (although cgo alters that). As debian/kFreeBSD is experimental at this time, I do not think it is worth the effort of duplicating all the freebsd specific code so this is proposal represents a reasonable workaround.
Currently cgo is not supported, make.bash will detect this and disable cgo automatically during the build.
dfc@debian:~/go/src$ uname -a
GNU/kFreeBSD debian 8.1-1-686 #0 Sat Jul 21 17:02:04 UTC 2012 i686 i386 Intel(R) Core(TM) i5-2415M CPU @ 2.30GHz GNU/kFreeBSD
dfc@debian:~/go/src$ ../bin/go version
go version devel +d05272f402ec Sat Dec 01 15:15:14 2012 -0800
Tested with GOOS=freebsd GOARCH=386
R=golang-dev
CC=golang-dev
https://golang.org/cl/6868046
Made the following changes:
- Export errprintf() from all three OS-specific modules
- Added errprintf() to a.h
- Moved errprintf() in windows.c under xprintf(), since they are so similar
- Replaced all instances of xprintf() with errprintf() where a vflag check is done
Fixes#3788.
R=golang-dev, alex.brainman
CC=golang-dev
https://golang.org/cl/6346056
If stdout and stderr are indeed the same file (not a tty), which is
often the case, fully-buffered stdout will make it harder to see
progresses, for example, ./make.bash 2>&1 | tee log
R=r, rsc
CC=golang-dev
https://golang.org/cl/5700070
When installing pprof into the tools directory, it needs to
have execute permissions on unix-like systems.
Fixes issues 3077.
R=golang-dev, rsc, minux.ma
CC=golang-dev
https://golang.org/cl/5675095
This CL makes it possible to run make.bash with
GOOS and GOARCH set to something other than
the native host GOOS and GOARCH.
As part of the CL, the tool directory moves from bin/tool/
to pkg/tool/goos_goarch where goos and goarch are
the values for the host system (running the build), not
the target. pkg/ is not technically appropriate, but C objects
are there now tool (pkg/obj/) so this puts all the generated
binaries in one place (rm -rf $GOROOT/pkg cleans everything).
Including goos_goarch in the name allows different systems
to share a single $GOROOT on a shared file system.
Fixes#2920.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5645093
Flush stdout before writing to stderr, to avoid
reordering output.
Allow amd64 from uname -m (FreeBSD).
TBR=golang-dev
CC=golang-dev
https://golang.org/cl/5629051
goc2c moves here.
parallel builds like old makefiles (-j4).
add clean command.
add banner command.
implement Go version check.
real argument parsing (same as 6g etc)
Windows changes will be a separate CL.
R=golang-dev, bradfitz, iant
CC=golang-dev
https://golang.org/cl/5622058
dist is short for distribution. This is the new Go distribution tool.
The plan is to replace the Makefiles with what amounts to
'go tool dist bootstrap', although it cannot be invoked like
that since it is in charge of getting us to the point where we
can build the go command.
It will also add additional commands to replace bash scripts
like test/run (go tool dist testrun), eventually eliminating our
dependence on not just bash but all the Unix tools and all
of cygwin.
This is strong enough to build (cc *.c) and run (a.out bootstrap)
to build not just the C libraries and tools but also the basic
Go packages up to the bootstrap form of the go command
(go_bootstrap). I've run it successfully on both Linux and Windows.
This means that once we've switched to this tool in the build,
we can delete the buildscripts.
This tool is not nearly as nice as the go tool. There are many
special cases that turn into simple if statements or tables in
the code. Please forgive that. C does not enjoy the benefits
that we designed into Go.
I was planning to wait to do this until after Go 1, but the
Windows builders are both broken due to a bug in either
make or bash or both involving the parsing of quoted command
arguments. Make thinks it is invoking
quietgcc -fno-common -I"c:/go/include" -ggdb -O2 -c foo.c
but bash (quietgcc is a bash script) thinks it is being invoked as
quietgcc -fno-common '-Ic:/go/include -ggdb' -O2 -c foo.c
which obviously does not have the desired effect. Rather than fight
these clumsy ports, I accelerated the schedule for the new tool.
We should be completely off cygwin (using just the mingw gcc port,
which is much more standalone) before Go 1.
It is big for a single CL, and for that I apologize. I can cut it into
separate CLs along file boundaries if people would prefer that.
R=golang-dev, adg, gri, bradfitz, alex.brainman, dsymonds, iant, ality, hcwfrichter
CC=golang-dev
https://golang.org/cl/5620045