Go: plugin: linker error when one plugin tries to open another plugin

[nzlov]

There is a problem that has been closed, but did not reply after asking.

20312

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

go version go1.9.1 linux/amd64

Does this issue reproduce with the latest release?

YES

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

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/workspace/go"
GORACE=""
GOROOT="/home/nzlov/program/go"
GOTOOLDIR="/home/nzlov/program/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build294433604=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?

DEMO

What did you expect to see?

What did you see instead?

runtime.main_main·f: relocation target main.main not defined
runtime.main_main·f: undefined: "main.main"

[davecheney]

This is working as intended. You need to include a main.main function in every plugin even if it is never called.

[nzlov]

@davecheney I have added main.main, but still being given. Have you tested my demo?

[davecheney]

The error is on this line

https://github.com/nzlov/testplugin/blob/master/Makefile#L4

Because you are not including main.go

Unlike many projects on GitHub, the Go project does not use its bug tracker for general discussion or asking questions. We only use our bug tracker for tracking bugs and tracking proposals going through the Proposal Process.

Please see https://golang.org/wiki/Questions for good places to ask questions.

[nzlov]

@davecheney Sorry.
Why include main.go?

 main.go  -> plugin.so(plugin.go) -> models.so(models.go)

I think is a bug,when plugin open other plugin.

[davecheney]

I'm sorry, that's just the way plugins work in Go, each plugin must have a main.main function. This is not used by the plugin, but is needed by the linker.

[nzlov]

@davecheney I'm sure I've added main.main.Can you make a demo ? Please.

[davecheney]

Please see https://golang.org/wiki/Questions for good places to ask questions.

I recommend asking on golang-nuts.

[nzlov]

@davecheney Sorry.
Please look demo.I have added func main(){},but still has error.

runtime.main_main·f: relocation target main.main not defined
runtime.main_main·f: undefined: "main.main"

I think is a bug...

[ianlancetaylor]

Sorry for the confusion. This is a bug when a plugin calls plugin.Open. Simple test case:

package main

import "plugin"

func F() {
    plugin.Open("x.so")
}

func main() {}

Compiling this with go build -buildmode=plugin produces

# command-line-arguments
runtime.main_main·f: relocation target main.main not defined
runtime.main_main·f: undefined: "main.main"

Removing the call to plugin.Open permits it to build, even if "plugin" is still imported.

[crawshaw]

Oops, sorry for missing this @nzlov. I'll look into it.

It does not appear to be related to the special handling for plugin.Open in the linker. Instead, the fact that plugin.Open calls runtime.plugin_lastmoduleinit brings extra symbols into the plugin that cause the confusion. Stubbing out the implementation of plugin_lastmoduleinit lets the program build.

[gopherbot]

Change https://golang.org/cl/69250 mentions this issue: cmd/link: dynamically import main.main in plugins

[gopherbot]

Change https://golang.org/cl/69370 mentions this issue: cmd/link, runtime: put hasmain bit in moduledata

[nzlov]

@crawshaw @ianlancetaylor Thank you for your help.

[d1vyank]

Are there any known workarounds for this until Go 1.10 is released?

[basantashah]

you dont have a main file in package main, if you could add a main function your issue will be solved