plugin.Open yields "built with a different version" error if built with custom GOMODCACHE path

[fxedel]

What version of Go are you using (go version)?

$ go version
go version go1.21.1 linux/arm64

(Docker golang:1.21.1 image)

Does this issue reproduce with the latest release?

yes (1.12.1 is the latest release)

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/root/.cache/go-build'
GOENV='/root/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_arm64'
GOVCS=''
GOVERSION='go1.21.1'
GCCGO='gccgo'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/src/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1732828847=/tmp/go-build -gno-record-gcc-switches'

What did you do?

See dockerized setup on fxedel/go-issue-63230.

I have two almost identical Go plugins, which both use an external (non-standard) library:

plugin-a/main.go:

package main

import (
	"fmt"

	_ "golang.org/x/xerrors"
)

func init() {
	fmt.Println("plugin-a init!")
}

plugin-b/main.go:

package main

import (
	"fmt"

	_ "golang.org/x/xerrors"
)

func init() {
	fmt.Println("plugin-b init!")
}

• plugin-a is built via go build -v -buildmode=plugin -o build/plugin-a.so ./plugin-a
• plugin-b is built via GOMODCACHE=/tmp go build -v -buildmode=plugin -o build/plugin-b.so ./plugin-b

Both plugins are loaded in my main program:

cmd/main.go:

import (
	"fmt"
	"os"
	"plugin"

	_ "golang.org/x/xerrors"
)

func main() {
	fmt.Println("main")
	fmt.Println(os.Getwd())

	fmt.Println("load plugin-a:")
	fmt.Println(plugin.Open("./build/plugin-a.so"))

	fmt.Println("load plugin-b:")
	fmt.Println(plugin.Open("./build/plugin-b.so"))
}

All files live in the same go module:
go.mod:

module github.com/fxedel/go-plugin-bug

go 1.21.1

require (
	golang.org/x/xerrors v0.0.0-20220907171357-04be3eba64a2
)

go.sum:

golang.org/x/xerrors v0.0.0-20220907171357-04be3eba64a2 h1:H2TDz8ibqkAF6YGhCdN3jS9O0/s90v0rJh3X/OLHEUk=
golang.org/x/xerrors v0.0.0-20220907171357-04be3eba64a2/go.mod h1:K8+ghG5WaK9qNqU5K3HdILfMLy1f3aNYFI/wnl100a8=

What did you expect to see?

Both modules are loaded, and plugin-a init! as well as plugin-b init! are printed to console.

What did you see instead?

Output of go run cmd/main.go:

go: downloading golang.org/x/xerrors v0.0.0-20220907171357-04be3eba64a2
main
/src <nil>
load plugin-a:
plugin-a init!
&{github.com/fxedel/go-plugin-bug/plugin-a  0x40000160c0 map[]} <nil>
load plugin-b:
<nil> plugin.Open("./build/plugin-b"): plugin was built with a different version of package golang.org/x/xerrors/internal

Further notes

I also tested this with another external package (golang.org/x/sys/unix), which is commented out in my demo repository. I guess that due to the different module cache directory, package paths are different and the Go runtime checks package version using the package path. However, this should not make a difference, as both plugins are built with the same library version (just at different locations).

[seankhliao]

use -trimpath if you don't want absolute file paths leaking into the binary.

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

For questions please refer to https://github.com/golang/go/wiki/Questions

[fxedel]

Hey @seankhliao, thanks for the reply. Adding -trimpath works, but unfortunately, I cannot always control the build options of the main binary (in particular, I'd like to create a plugin for krakend). I guess this issue is related to (or even duplicates?) #26759.