When -mretpoline is enabled with clang, a __llvm_retpoline_r11 weak symbol
is emitted in each compilation unit. This results in the Go linker
complaining when processing a package archive that contains cgo linkages,
since it finds the same weak symbol defined in multiple object files.
Relax the duplicate symbol detection such that weak symbols are permitted
to be duplicated. This makes it possible to build Go with clang again and
addresses a similar duplicate weak symbol issue that results from retguard.
Also backport an upstream commit that corrects the handling of libgcc vs
libcompiler_rt. Combined with the above fix `make regress` now passes with
both gcc and clang.
ago, output from this is really very noisy.
since the build with no flags is silent, add -v as a middle ground by
defaulot, so you can see that something is happening during the build,
but without so much console spam.
ok jasper@
- Disable the Go 1.10 test caching via GOCACHE - this seems to interact
badly with the ports build infrastructure and does not provide any
real benefit in this environment.
- Provide a MODGO_TEST_FLAGS variable that allows ports to specify test
flags.
ok jasper@
This requires three changes:
- OpenBSD clang produces __guard_local symbols that are marked as hidden,
which causes problems with the go linker. Workaround this by explicitly
making __guard_local symbols visible when reading in an ELF object.
- OpenBSD clang currently fails to correctly report the compiler runtime
via --print-libgcc-file-name. Workaround this issue by hardcoding it
for the time being.
- The TestCgoConsistentResults test passes successfully outside of ports,
however fails under a ports build. This requires further investigation
but we can just skip the test for now.
- create a new MODGO_LDFLAGS variable
- set MODGO_LDFLAGS to "-s -w" by default (no DEBUG)
- add -ldflags="${MODGO_LDFLAGS}" to the build and test CMDs if
MODGO_LDFLAGS is defined
ok czarkoff@ jsing@
Go libraries should be rebuilt on every lang/go update. This change adds
runtime dependency on lang/go for ports with "lib" in MODGO_TYPE, and tunes
PKGSPEC to force dependency on exact version of go.
OK jsing@, "makes sense" sthen@
Go 1.6 pass regress on openbsd/386 and openbsd/amd64. Also stop exporting
environ and __progname from cgo, since these symbols are no longer required
by libc.
sigreturn syscall is going away in future versions of OpenBSD and its
use for Go is already broken due to the trampoline return checks. Instead
just return directly from the signal trampoline (as we have always done
for Go openbsd/amd64).
Also fix a bug in the Go openbsd/386 linker, which results in symbols in
the dynamic symbol table being emitted with a size of zero. With a current
ld.so, this results in symbol mismatch warnings.
Unbreaks the Go port on openbsd/386, however it still fails to pass regress
due to the PT_TLS changes.
some ports that used to depend on GO15VENDOREXPERIMENT=1 need 1.6 or they
won't build as the usage of that variable has been removed in their Makefiles.
ok czarkoff@ sthen@
Clear user's environment with SETENV and provide MODGO_ENV for adding variables
to environment and MODGO_GOPATH for altering GOPATH.
OK ajacoutot@, jasper@, kspillner@
https://groups.google.com/forum/#!topic/golang-announce/9eqIHqaWvck
"Go's crypto libraries passed certain parameters unchecked to the
underlying big integer library, possibly leading to extremely
long-running computations, which in turn makes Go programs vulnerable to
remote denial of service attacks. Programs using HTTPS client
certificates or the Go SSH server libraries are both exposed to this
vulnerability.
This is CVE-2016-3959 and was addressed by this change:
https://golang.org/cl/21533
Thanks to David Wong for identifying this issue."
without -a, -work and without running things through sed and piping to
shell:
- Install additional packages under /usr/local/go-pkg and include this in
GOPATH when building. Go considers anything under the GOROOT to be part
of the standard library, which introduces various problems. In particular
they do not get rebuilt without the -a flag.
- Using 'go build -a' is unnecessary (at least now that we're not
installing in GOROOT). Furthermore, the semantics of -a have changed
between go1.4 and go1.5. In go1.4 the standard library was excluded from
the -a flag whereas for go1.5 it does mean all dependencies including the
standard library (this was the same for go1.3). However, there is
already blanket 'do not rebuild standard library packages' in place when
the -a flag is NOT specified.
- Avoid -work since it leaves the work directory behind and nothing is
currently cleaning it up.
- Overall, avoid running 'go install -x' and piping the results through
sed and sh. Firstly, 'go install -x' is already running those commands,
then they're being run a second time around via sh. Secondly, there are
cases where replacing GOROOT is incorrect.
ok jasper@ sthen@ kspillner@ czarkoff@
