Since CL 393354 this should no longer be necessary.
Change-Id: Ie9a7f779515aaf8b40a4f0083ba680f7b0231f04
Reviewed-on: https://go-review.googlesource.com/c/go/+/585576
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Kirill Kolyshkin <kolyshkin@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The comment justifies exporting GOROOT by saying the api test needs it,
which was relevant back when it was added in CL 99870043, but isn't true
by now.
As of Go 1.8, GOPATH can be unset (https://go.dev/doc/go1.8#gopath).
At some point it also became okay to leave GOROOT unset, at least
whenever one is looking to use the default GOROOT tree of the go command
being executed and not intentionally changing it to a custom directory.
It's also not there in the .bat and .rc variants of this script.
Drop it.
Change-Id: Ibcb386c560523fcfbfec8020f90692dcfa5aa686
Reviewed-on: https://go-review.googlesource.com/c/go/+/480376
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
These environment variables affect cmd/dist, and in turn run.bash.
They exist primarily for the Go build system, but are still needed
sometimes when investigating problems. Document them in one place.
Fixes#46054.
Change-Id: I5dea2ac79b0d203d2f3c9ec2980382f62bead5cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/455517
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
'go tool' sets environment variables, including the GOAMD64 value
from the user's go.env file.
'go tool dist test' then rebuilds and reinstalls the toolchain and
standard library based on those variables. It should not; instead, it
should test exactly the configuration installed by the make scripts.
Fixes#54084.
Change-Id: I7cc8a21cc1d8331e06d7b7c55b14d170f8e2faab
Reviewed-on: https://go-review.googlesource.com/c/go/+/420055
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
'go tool dist env' outputs different (and fewer) environment variables
than 'go env'. The 'go tool dist env' variables should be
authoritative, whereas many printed by 'go env' are merely
informational (and not intended to be overridden in the actual
environment).
Fixes#52009
Change-Id: Ic0590153875183135cebf7ca55ead7c2b4038569
Reviewed-on: https://go-review.googlesource.com/c/go/+/398061
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
We used to clear GOPATH in all the build scripts.
Clearing GOPATH is misleading at best, since you just end up
with the default GOPATH (%USERPROFILE%\go on Windows).
Unless that's your GOROOT, in which case you end up with a
fatal error from the go command (#43938).
run.bash changed to setting GOPATH=/dev/null, which has no
clear analogue on Windows.
run.rc still clears GOPATH.
Change them all to set GOPATH to a non-existent directory
/nonexist-gopath or c:\nonexist-gopath.
Change-Id: I51edd66d37ff6a891b0d0541d91ecba97fbbb03d
Reviewed-on: https://go-review.googlesource.com/c/go/+/288818
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
https://golang.org/doc/contribute.html#quick_test currently suggests
running 'make.bash' and 'run.bash' separately, but 'run.bash'
potentially uses a 'go' command resolved from the wrong GOROOT,
which in turn sets the wrong GOROOT for further commands.
Updates #32674
Updates #17896
Change-Id: I4925d478d0fc7351c4f6d40830ab17d4d688348d
Reviewed-on: https://go-review.googlesource.com/c/go/+/223741
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Even with 10 shards on builders, it still takes about ~2.5 minutes per
shard (and getting slower all the time as the test/ directory grows).
I'm currently experimenting with massively sharding out testing on
Cloud Run (each dist test & normal TestFoo func all running in
parallel), and in such a setup, 2.5 minutes is an eternity. I'd like
to increase that dist test's sharding from 10 to more like 1,000.
Updates golang/go#31834
Change-Id: I8b02989727793b5b5b2013d67e1eb01ef4786e28
Reviewed-on: https://go-review.googlesource.com/c/go/+/175297
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This also updates the vendored-in versions of several packages: 'go
mod vendor' selects a consistent version of each module, but we had
previously vendored an ad-hoc selection of packages.
Notably, x/crypto/hkdf was previously vendored in at a much newer
commit than the rest of x/crypto. Bringing the rest of x/crypto up to
that commit introduced an import of golang.org/x/sys/cpu, which broke
the js/wasm build, requiring an upgrade of x/sys to pick up CL 165749.
Updates #30228
Updates #30241
Updates #25822
Change-Id: I5b3dbc232b7e6a048a158cbd8d36137af1efb711
Reviewed-on: https://go-review.googlesource.com/c/go/+/164623
Reviewed-by: Filippo Valsorda <filippo@golang.org>
The standard build assumes the variable is unset.
Make it so, like we do for GOFLAGS, GOBIN, and so on.
Change-Id: I4ad5695f8021b08bd1a35dd99112970a813d247c
Reviewed-on: https://go-review.googlesource.com/c/149959
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
People sometimes want to turn on a particular go command flag by default.
In Go 1.11 we have at least two different cases where users may need this.
1. Linking can be noticeably slower on underpowered systems
due to DWARF, and users may want to set -ldflags=-w by default.
2. For modules, some users or CI systems will want vendoring always,
so they want -getmode=vendor (soon to be -mod=vendor) by default.
This CL generalizes the problem to “set default flags for the go command.”
$GOFLAGS can be a space-separated list of flag settings, but each
space-separated entry in the list must be a standalone flag.
That is, you must do 'GOFLAGS=-ldflags=-w' not 'GOFLAGS=-ldflags -w'.
The latter would mean to pass -w to go commands that understand it
(if any do; if not, it's an error to mention it).
For #26074.
For #26318.
Fixes#26585.
Change-Id: I428f79c1fbfb9e41e54d199c68746405aed2319c
Reviewed-on: https://go-review.googlesource.com/126656
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
POSIX Shell only supports = to compare variables inside '[' tests. But
this is Bash, where == is an alias for =. In practice they're the same,
but the current form is inconsisnent and breaks POSIX for no good
reason.
Change-Id: I38fa7a5a90658dc51acc2acd143049e510424ed8
Reviewed-on: https://go-review.googlesource.com/38031
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Set $GOPATH to a semantically valid, non-empty string that cannot
conflict with $GOROOT to avoid false test failures that occur when
$GOROOT resides under $GOPATH. Unsetting GOPATH is no longer viable
as Go now defines a default $GOPATH that may conflict with $GOROOT.
Fixes#19237
Change-Id: I376a2ad3b18e9c4098211b988dde7e76bc4725d2
Reviewed-on: https://go-review.googlesource.com/37396
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
I'm tired of having to remember it on every command.
Rebuilding everything is the wrong default.
This CL updates the build script, but the builders may
(or may not) need work, depending on whether they
rebuild using the test command (I doubt it).
Change-Id: I21f202a2f13e73df3f6bd54ae6a317c467b68151
Reviewed-on: https://go-review.googlesource.com/18084
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This will enable test sharding over multiple VMs, to speed trybot answers.
Update #10029
Change-Id: Ie277c6459bc38005e4d6af14d22effeaa0a4667e
Reviewed-on: https://go-review.googlesource.com/6531
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This is a followup to http://golang.org/cl/6280.
clang -pie fails to link misc/cgo/test on freebsd-amd64.
Change-Id: I6f9575d6bb579f4d38d70707fb9c92e303e30e6f
Reviewed-on: https://go-review.googlesource.com/6520
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
PIE binaries can be built by the Go compiler in external link mode with
extldflags="-pie". These binaries support ASLR (address space layout
randomization) when executed on systems with appropriate kernel/dynamic
linker support.
This CL enables some cgo tests to run with -pie as a sanity check (in
addition to the other linker flag combinations they already test).
I have tested this functionality more thoroughly by building the full
compiler testsuite (test/...) and standard library tests with -pie
and executing them remotely on ChromeOS devices for all three linux
architectures (linux_amd64, linux_386, and linux_arm).
Change-Id: I3f644a72e94c3341f3360dfee58db5ec3a591e26
Reviewed-on: https://go-review.googlesource.com/6280
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The wildcard 'std' is defined in documentation to be all the packages
in the Go standard library. It has also historically matched commands
in the main repo, but as we implement core commands in Go, that
becomes problematic. We need a wildcard that means just the library,
and since 'std' is already documented to have that definition, make it so.
Add a new wildcard 'cmd' for the commands in the main repo ($GOROOT).
Commands that want both can say 'std cmd' (or 'cmd std') to get the
effect of the old 'std'.
Update make.bash etc to say both std and cmd most of the time.
Exception: in race.bash, do not install race-enabled versions of
the actual commands. This avoids trying to write binaries while
using them, but more importantly it avoids enabling the race
detector and its associated memory overhead for the already
memory-hungry compilers.
Change-Id: I26bb06cb13b636dfbe71a015ee0babeb270a0275
Reviewed-on: https://go-review.googlesource.com/5550
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Now that there's no 6c compiler anymore, there's no need for cgo to
generate C headers that are compatible with it.
Fixes#9528
Change-Id: I43f53869719eb9a6065f1b39f66f060e604cbee0
Reviewed-on: https://go-review.googlesource.com/2482
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This implements support for calls to and from C in the ppc64 C ABI, as
well as supporting functionality such as an entry point from the
dynamic linker.
Change-Id: I68da6df50d5638cb1a3d3fef773fb412d7bf631a
Reviewed-on: https://go-review.googlesource.com/2009
Reviewed-by: Russ Cox <rsc@golang.org>
The freebsd-386 and freebsd-amd64 builders are timing out sometimes.
This will give them some more breathing room.
Change-Id: Ib65bd172cca046a52861759a4232d7b4b6514fa8
Reviewed-on: https://go-review.googlesource.com/1994
Reviewed-by: Ian Lance Taylor <iant@golang.org>
People keep pasting all.bash output into GitHub bugs, which turns
the # lines into <h1> headlines. Add some more #s so that the
bug reports are more readable. Not ideal but seems like the best
of a few bad options.
Change-Id: I4c69930ec304b2d504d7cd66221281a8577b87ae
Reviewed-on: https://go-review.googlesource.com/1286
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
This is the last system-dependent file written by cmd/dist.
They are all now written by go generate.
cmd/dist is not needed to start building package runtime
for a different system anymore.
Now all the generated files can be assumed generated, so
delete the clumsy hacks in cmd/api.
Re-enable api check in run.bash.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/185040044
The assumption can be violated by external linkers reordering them or
inserting non-Go sections in between them. I looked briefly at trying
to write out the _go_.o in external linking mode in a way that forced
the ordering, but no matter what there's no way to force Go's data
and Go's bss to be next to each other. If there is any data or bss from
non-Go objects, it's very likely to get stuck in between them.
Instead, rewrite the two places we know about that make the assumption.
I grepped for noptrdata to look for more and didn't find any.
The added race test (os/exec in external linking mode) fails without
the changes in the runtime. It crashes with an invalid pointer dereference.
Fixes#9133.
LGTM=dneil
R=dneil
CC=dvyukov, golang-codereviews, iant
https://golang.org/cl/179980043
Otherwise no system will get an 'ok' until they all do.
LGTM=r, dave
R=r, dave
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/170320044
Corrections due to new strict type rules for data+bss.
Also disable misc/cgo/cdefstest since you can't compile C code anymore.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/148050044
Normally, the caller to runtime.entersyscall() must not return before
calling runtime.exitsyscall(), lest g->syscallsp become a dangling
pointer. runtime.cgocallbackg() violates this constraint. To work around
this, save g->syscallsp and g->syscallpc around cgo->Go callbacks, then
restore them after calling runtime.entersyscall(), which restores the
syscall stack frame pointer saved by cgocall. This allows the GC to
correctly trace a goroutine that is currently returning from a
Go->cgo->Go chain.
This also adds a check to proc.c that panics if g->syscallsp is clearly
invalid. It is not 100% foolproof, as it will not catch a case where the
stack was popped then pushed back beyond g->syscallsp, but it does catch
the present cgo issue and makes existing tests fail without the bugfix.
Fixes#7978.
LGTM=dvyukov, rsc
R=golang-codereviews, dvyukov, minux, bradfitz, iant, gobot, rsc
CC=golang-codereviews, rsc
https://golang.org/cl/131910043
misc/cgo/testgodefs was added by revision d1cf884a594f, but not
add to run.bash.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/129760044
Add nacl.bash, the NaCl version of all.bash.
It's a separate script because it builds a variant of package syscall
with a large zip file embedded in it, containing all the input files
needed for tests.
Disable various tests new since the last round, mostly the ones using os/exec.
Fixes#7945.
LGTM=dave
R=golang-codereviews, remyoudompheng, dave, bradfitz
CC=golang-codereviews
https://golang.org/cl/100590044
Some system doesn't have libc.a available.
While we're at here, also export GOROOT in run.bash, so that
one doesn't need to set GOROOT to run run.bash.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/99870043
We get
/usr/lib/libc.a(stack_protector.o): In function `__stack_chk_fail_local':
stack_protector.c:(.text+0x158): multiple definition of `__stack_chk_fail_local'
/var/tmp/go-link-04838a/000001.o:/tmp/gobuilder/netbsd-386-minux-c7a9e9243878/go/src/pkg/runtime/cgo/gcc_386.S:41: first defined here
I am assuming this has never worked and possibly is not intended to work.
(Some systems are vehemently against static linking.)
TBR=iant
CC=golang-codereviews
https://golang.org/cl/88130046
Record what's going on in case someone is debugging a failure there.
It's not Go's fault.
Fixes#7381.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/68200043
CL 64170043 disabled it in run.bash for Unix systems.
I did not realize Windows systems also ran the race detector test.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/64480043
