trimpath can be inconvenient for IDEs and LSPs that do not always
correctly handle module relative paths, and can also contribute to
caching bugs taking effect. We rarely have a real need for trimpath of
test produced binaries, so avoiding it should be a net win.
Updates #2988
Signed-off-by: James Tucker <james@tailscale.com>
We don't build a lot of tools with CGO, but we do build some, and it's
extremely valuable for production services in particular to have symbols
included - for perf and so on.
I tested various other builds that could be affected negatively, in
particular macOS/iOS, but those use split-dwarf already as part of their
build path, and Android which does not currently use gocross.
One binary which is normally 120mb only grew to 123mb, so the trade-off
is definitely worthwhile in context.
Updates tailscale/corp#20296
Signed-off-by: James Tucker <james@tailscale.com>
Tracking down the side effect can otherwise be a pain, for example on
Darwin an empty GOOS resulted in CGO being implicitly disabled. The user
intended for `export GOOS=` to act like unset, and while this is a
misunderstanding, the main toolchain would treat it this way.
Fixestailscale/corp#20059
Signed-off-by: James Tucker <james@tailscale.com>
The new 'toolchain' directive in go.mod can sometimes force
the use of an upstream toolchain against our wishes. Concurrently,
some of our dependencies have added the 'toolchain' directive, which
transitively adds it to our own go.mod. Force all uses of gocross to
ignore that directive and stick to our customized toolchain.
Updates #cleanup
Signed-off-by: David Anderson <danderson@tailscale.com>
It's used to control various opt-in functionality for the macOS and iOS
apps, and was lost in the migration to gocross.
Updates tailscale/tailscale#7769
Signed-off-by: Mihai Parparita <mihai@tailscale.com>
Xcode changed how/what data it exports to build steps at some point
recently, so our old way of figuring out the minimum support version
for clang stopped working.
Updates tailscale/corp#4095
Signed-off-by: David Anderson <danderson@tailscale.com>
