go version)?go 1.9.1
yes
go env)?does not matter (linux, windows)
When I run go build -gcflags -trimpath somepath go will execute go tool compile -trimpath $WORK -trimpath somepath during build process. Due to this default -trimpath $WORK is not effective.
Another use case is go build -gcflags -trimpath $GOPATH because I want to prevent storing my username (from the homedir) to built binaries and I have more directories in the GOPATH.
all trimpath arguments are used
last trimpath argument is used
Thanks, but you are describing a solution rather than a problem. What is the real goal? What paths do you want to trim and why?
I have configuration where there are two gopaths. And both of them show local system information (e.g. my username). I want to remove these paths from the project and keep only src/... part and this is the only method which currently helps.
But trimpath supports only one path and by this default remove of $WORK directory is not working anymore.
I'm encountering this issue when I'm compiling a program using cgo (with Go 1.10). For example, for this program:
package main
// typedef int (*intFunc) ();
//
// int
// bridge_int_func(intFunc f)
// {
// return f();
// }
//
// int fortytwo()
// {
// return 42;
// }
import "C"
import "fmt"
func main() {
f := C.intFunc(C.fortytwo)
fmt.Println(int(C.bridge_int_func(f)))
// Output: 42
}
If I compile this program with no trimpath flags (go build fortytwo.go), the executable will have these two paths:
/home/jeff/fortytwo.go
_cgo_gotypes.go
If I compile with trimpath flags (go build -gcflags "all=-trimpath=/home/jeff" -asmflags "all=-trimpath=/home/jeff" fortytwo.go), the executable will have these two paths:
fortytwo.go
/tmp/go-build073316115/b001/_cgo_gotypes.go
Because I supplied the trimpath flags, the built-in -trimpath $WORK is overridden. Neither option is great in terms of reproducibility; ideally both paths are trimmed.
This issue should be more relevant now with modules, since the project you're building can be outside the $GOPATH while modules that your project depends on are built inside $GOPATH.
I agree with @jclc that this issue is relevant when using modules, since it is impossible to remove $GOPATH/pkg strings from your binary if you are already using -trimpath on any other location.
I suppose that there are a few of ways to solve this, and I would be curious to which one is most amenable to the Go community:
Teach -trimpath to respect os.PathListSeparator, so that we could say: -trimpath=$(pwd):$GOPATH/pkg, or similar.
Teach cmd/compile to respect multiple -trimpath arguments, which I believe would address issues like https://github.com/golang/go/issues/24976, too.
Add additional semantics to _always_ trim $GOPATH/pkg or others from the compiled binary. This option seems too mysterious to me, but I would defer to the judgement of others.
I'd be happy myself to write a patch for any of the above three.
Instead of multiple paths, probably we should have some mode that means “trim all paths that aren't part of the import path”. That would help with cases like #28008 where the caller doesn't actually know the full set of paths in play.
Instead of multiple paths, probably we should have some mode that
means “trim all paths that aren't part of the import path”.
I think that is a sensible way to go. It's a good sign that this is
better than multiple -trimpath's, because:
Invocations like 'go build -gcflags="-trimpath=$PWD:$GOPATH/pkg"'
will get copied around all over the place, and
The above doesn't spell a way to exclude things in /tmp, which mean
that builds can't be reproducible under this mechanism. Certainly
an option "exclude any path prefix outside of $PWD" would take care
of that.
What would it be called?
Users should not be using -trimpath. The general problem here is #16860.
Most helpful comment
Instead of multiple paths, probably we should have some mode that means “trim all paths that aren't part of the import path”. That would help with cases like #28008 where the caller doesn't actually know the full set of paths in play.