plugin: requires CGO_ENABLED=1

[johanbrandhorst]

Please answer these questions before submitting your issue. Thanks!

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

go version go1.8 linux/amd64

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

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

What did you do?

I tried to build a simple plugin with CGO_ENABLED=0. It builds fine, and at plugin load time you get an error plugin: not implemented. This is an intentional limitation at the moment, but I think it moves backwards in the general trend of the language development, which has been moving away from C dependencies. This should hopefully be a discussion around supporting plugins without the need for CGO.

What did you expect to see?

I expected to be able to build and load plugins without CGO.

What did you see instead?

I got an error saying plugin: not implemented.

[bradfitz]

/cc @crawshaw @ianlancetaylor

[emilevauge]

Ouch, this one is really annoying as it prevents from using plugins with a statically linked golang executable (made for Docker containers).

[ianlancetaylor]

The implementation of plugins requires the dynamic linker, so it will not work with statically linked executables. Changing that would be hard. There are no plans to do it.

[gopherbot]

CL https://golang.org/cl/43158 mentions this issue.

[odeke-em]

I've mailed https://go-review.googlesource.com/43158 for starters.

[johanbrandhorst]

Wouldn't this technically break the backwards compatibility promise? Since in 1.8 these builds compile fine with runtime errors.

[ianlancetaylor]

As noted on the CL, I don't think preventing programs that import the plugin package from building is the right approach. And if we do think it is the right approach, we can do that by simply changing the plugin package to fail in some way when cgo is not available.

[1x-eng]

Is there any update on this yet?

In the context of AWS Lambda, if CGO_ENABLED=1, GO lambda runs into these errors -

/var/task/main: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /var/task/main)
/var/task/main: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by /var/task/main)

With CGO_ENABLED=0, the lambda is healthy, however, it cannot leverage/use a plugin. As posted by @johanbrandhorst , with CGO_ENABLED=0, using a plugin results in plugin: not implemented

[anakinkinsey]

@1x-eng I managed to run plugins in a lambda today without either of those errors. I did compile with CGO_ENABLED=1