To answer my own question, it turned out the problem was a change in behaviour in dh-golang (Debian helper for golang). This changed the build flags used by the default (non-overridden) Go build behaviour to use '-all' with 'trimpath', which changed the file paths embedded in the compiled code. As the plugins use an override to build (dh-golang doesn't allow for buildmode=plugin), this caused the paths for the exact same shared code to appear to be different, and the plugins wouldn't load.
I'd be interested if anyone can explain why the default Go behaviour is not to trim paths back to the root of GOPATH, given the problems this can cause with plugins. To my mind, the current hashing algorithm used to check plugins have been built with the same version as the caller of the plugin is actually wrong, as it rejects plugins built with the same code as the caller of the plugin. Using trimpath / all flags is a workaround, but no more than that. Regards, William On Thursday, 5 September 2019 17:48:01 UTC+1, William Ivory wrote: > > Hi, > > I've been using Go plugins with Go1.10, and after initial problems getting > our build system to build using identical paths to avoid the dreaded > 'plugin was built with a different version of package' error, it all > settled down and was working well for 6 months or so. We're now trying to > switch to Go1.11, and the exact same code and Debian build rules now > consistently produces the 'different version' error. Is anyone aware of > any changes between Go1.10 and Go1.11 that might explain this? > > Thanks, > > William > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/5c8ab433-7ecc-42ec-8dc1-fe8a73528d1c%40googlegroups.com.
