`GOOS` and `GOARCH` can be set to cross compile the Go code. But
`good-names.go` is generated at build time using `mknames.go`, which
must be built for the build platform. `GOOS` and `GOARCH` can be unset
to do this. In many circumstances, Go will use its own internal linker
to build the binary, which means it won't need to use `$CC`. But in
some scenarios, e.g. when building PIE binaries, it will use `$CC` as
the linker, so this needs to be set to the build platform's compiler
for `go run`.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This bug, reported by David Runge, identifies another regression
vs. libpsx-2.71:
https://bugzilla.kernel.org/show_bug.cgi?id=219687
A regression of the LWP threading support reintroduced an old bug
in the libpsx-2.72 rewrite, specifically this bug:
https://github.com/golang/go/issues/42494
This present change includes x86_64, i386 and arm* (32-bit and 64-bit)
support. I've tested each of these with debian OSes, some running via QEMU.
Before releasing 2.74, I plan to extend the testing to all of the targets
supported by Debian (see https://wiki.debian.org/DebianInstaller/Qemu).
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This addresses the following bug:
https://bugzilla.kernel.org/show_bug.cgi?id=219456
insofar as it eliminates the need for -wrap=pthread_create
linkage. Mostly, code that uses -lpsx functions can simply
link with -lpsx now. However, for legacy reasons the library
still works when linked wrapped or with the new content of
the libpsx.pc file:
-Wl,--no-as-needed -Wl,--whole-archive -lpsx -Wl,--no-whole-archive -Wl,--as-needed -lpthread
These last options are required for getting -lcap to act at a
consistent process level and not a thread level.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Discussion and explanation of what is up here is in:
https://bugzilla.kernel.org/show_bug.cgi?id=219169
This gets the Go cap package to parity with the recent changes to
libcap. This change will be live in cap/v1.2.71.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
When run via sudo, compare-cap exits with some file capabilities
left on its binary file. This is a test binary, so that's not a
big problem, however, it does mean that a 2nd run of the program
is started with, potentially, a different initial state.
This commit fixes that exit condition and addresses:
https://bugzilla.kernel.org/show_bug.cgi?id=217018
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
$ make
$ sudo go/captrace your-program
will attempt to explore what capabilities are needed to run
your program by observing when cap_capable() inside the kernel
is associated with your-program.
Other ways to invoke this are
$ sudo go/captrace --pid=<pid>
$ sudo go/captrace
The last of these traces everything running on a system.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
I'm not 100% sure this is needed, but I'm not yet convinced
'make distclean && make -j48 test' works reliably, but I find this
easier to reason about.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Missed a vendor dependency for the ok.go file. More recent go releases
seem more picky about module or vendoring being used, and for the in-tree
builds we consistently use vendoring. So make sure the vendoring
directory set up has completed before trying to build ok.go.
The failure was reported by Tomasz Kłoczko.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
It looks like go1.18 is going to default to CGO_ENABLED=0, so force
CGO_ENABLED=1 when building this cap-libcap comparison program.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=215603
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
The CGO_ENABLED=0 failure mode is discussed in:
https://github.com/golang/go/issues/50113
At the present time, this only passes when the psx package is compiled
CGO_ENABLED=1. The problem being that a blocking read cannot be
interrupted by the CGO_ENABLED=0 build of package "psx". It does not
deadlock when compiled CGO_ENABLED=1 because the psx signal wakes the
reading thread up back into user space.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
When a syscall that yields different return values is called from
the Go psx.Syscall*() API, we want to mirror the behavior of the
native golang runtime.AllThreadsSyscall() function.
The previous inconsistency was pointed out by Lorenz Bauer in:
https://bugzilla.kernel.org/show_bug.cgi?id=215283#c8
[I decided to defer this change until 2.63, and not include this
in the bug-fix for 215283, on the grounds it is a slight
incompatibility in runtime behavior, and wanted to give folk an
opportunity to plan for it. This new behavior enforcement will
crash an unprepared go program.]
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Lorenz Bauer found a race condition in the cap.Launcher teardown
process and reported it here:
https://bugzilla.kernel.org/show_bug.cgi?id=215283
This seems to significantly improve the situation. I'm going to
study the test case some more, but this is definitely part of the
solution.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
I've been looking at reasons packagers are not building the Go binaries
and found this with respect to RPMs:
https://github.com/rpm-software-management/rpm/issues/367
There has been no easy way to inject the otherwise unneeded workaround:
-ldflags=-linkmode=external for building (which, strangely, generates
some sort of warning and gratuitously links glibc to an otherwise
static build), but seems to work.
Until RPM supports Go's native '.note.go.buildid', and RPM requires
'.note.gnu.build-id' on binaries, I guess this can work around it:
GO_BUILD_FLAGS='-ldflags=-linkmode=external'
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Noticed that we weren't applying the same amount of flag discipline
to local BUILD_* tool rules. Fixing that, I see we've been carrying
a source code issue in libcap/_makenames.c for a while. (FIXED).
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
We also add the cap.ProcRoot() API to let the user redirect to their
local /proc/ directory - in case anyone runs with an unusual setup
like that.
I've been studying the downstream package definitions and no one
it doesn't seem popular to build the Go packages. Indeed, Go folk
themselves prefer to install via modules anyway, so we're getting
with the program.
However, if folk want to build test the Go stuff as part of a package
build and run an install as well, we reward them with the 'captree'
binary.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
