Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: Allow building non-main package with -buildmode=plugin #18124

captncraig opened this Issue Nov 30, 2016 · 4 comments


None yet
7 participants
Copy link

captncraig commented Nov 30, 2016

The plugin package currently requires a main package as an entry point to use -buildmode=plugin. I would like to use the plugin package to load library packages at runtime, which are only used for their initializers. Plugins usually look like:

package myPlugin

import ""

func init(){

The current methodology is that these are compiled into the host with import _ "myPlugin" In order to support loading at runtime as well, each plugin needs a second main package that is literally:

package main

import _ "myPlugin"

func main(){}

This feels like unnecessary boilerplate. At Ian's suggestion I propose modifying the go tool to generate such a main package when using -buildmode=plugin and a single non-main package is built.

I plan on working on this feature.


This comment has been minimized.

Copy link

captncraig commented Nov 30, 2016

Turns out this is not so easy. This solution would solve my immediate use case, but only because my plugins do not need to export anything. The generated main package hides the exports from the actual package you want to build, and the host app won't be able to find them with Lookup.

The only solution I can think of is essentially rewriting all go files in the package to a tmp directory and rewriting the import to main. Probably out of scope of what you would be willing to accept for this.

Any other ideas?


This comment has been minimized.

Copy link

ianlancetaylor commented Dec 1, 2016

I see, you're right, I was thinking more of c-shared and c-archive, where any package can export a symbol (by using a magic cgo //export comment). For plugins I think you really do have to write a main package, except, of course, for your use case which I think is too uncommon to treat specially.


This comment has been minimized.

Copy link

captncraig commented Dec 1, 2016

Does it not seem a bit silly needing to write a main function that never gets executed though?


This comment has been minimized.

Copy link

Kubuxu commented Jul 13, 2017

I also just hit this issue, as we want to support either dynamic loading of plugins or preloading them during build of the program, I will be generating mainpackage for all plugins during build process.

This will only work for us as we use single variable export as entry point of plugins.

@rsc rsc modified the milestones: Go1.10, Go1.11 Dec 1, 2017

@gopherbot gopherbot modified the milestones: Go1.11, Unplanned May 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.