On Tuesday, March 21, 2017 at 5:59:11 PM UTC+1, Ian Lance Taylor wrote:
Well, there are no Go plugin gurus, and to be honest I'm starting to > think it was a mistake to let the plugin package into 1.8. I know > that is not what you want to hear. It's in because the API seems OK, > but it has become clear that there are many related issues that we > haven't thought about. Well, certainly you Ian Lance Taylor are infinitely more a Go plugin guru than I (Basile) am today, and I thank you for spending some time to answer my newbie questions. If I understand your example, your plugin imports a package, and your > main program also imports the same package, and it's unfortunate that > the package gets linked into both the plugin and the main program. > That is true. > Thanks for the insight. I'm still not at ease with go build command, and I am a bit stressed by lack of build directives (e.g. some Makefile like thing instructing the build automation tool for particular options, such as -buildmode=shared & -linkshared etc...) Bear in mind that I am a Go newbie and the plugin abilities of Go1.8 are absolutely essential to me, since I want to generate Go code at runtime, compile it as a plugin, and load it as a plugin (all that in the same process, with the compilation step using some external command, e.g. forking some go build process, probably thru my -buggy- build-plugin-monimelt.sh <https://github.com/bstarynk/monimelt/blob/master/build-plugin-monimelt.sh> shell script). BTW, I am not alone in wanting this: Sandeep Kalra is asking something quite similar in his []byte to func <https://groups.google.com/forum/#!topic/golang-nuts/AazLcta3Nos> question (even if he formulates his question very differently). I'm coding monimelt <https://github.com/bstarynk/monimelt> (on github) and I just realize that my build procedure is badly broken (in today's commit 974dda17acc7 <https://github.com/bstarynk/monimelt/commit/974dda17acc7eeb5d41b61b6466e4ddeddab4bd9>) First, is Svetlin's golang-sharing-libraries <http://blog.ralch.com/tutorial/golang-sharing-libraries/> tutorial still *exactly* correct for Go1.8 *specifically*? Its title *Sharing Golang packages to C and Go* is a bit misleading. I just want all my non-main packages to be "shared objects" in Linux parlance (because I really don't want them to be compiled twice, once for the main program and once for the plugin). I don't care if each of my package has its own *.so file, or if all of them are agglomerated in one single *.so file. BTW, I would prefer to avoid having tons of *.so files (what I would probably prefer is to have all the non-main code of my thing as a *single* *.so file shared between main program & plugins). In particular, is issue 12236 <https://github.com/golang/go/issues/12236> still relevant for Go 1.8 ? I think the only way to deal with is going to be to > compile the shared package with -buildmode=shared, and build both the > plugin and the main program with -linkshared. In fact that is what > you suggest. Does it work? I don't know whether it does or not. My main concern is that I don't want to compilation of a *small* plugin taking a lot of time to recompile all the code used by that particular plugin and *already provided & linked* in the main program loading it. I expect (like GCC MELT did for C and C++ code) that, when generating only a few hundred lines of Go source lines (the simplest case is a few hundred lines in a single /tmp/generated.go file with package main as source code of a plugin which is importing *many* packages built in the main program, such as go-sqlite3 <https://github.com/mattn/go-sqlite3> which contains sqlite3 agglomeration C code so takes many seconds to be compiled), its compilation time as a *plugin* should be quick (probably a fraction of a second). I am not sure to understand well how -buildmode=shared & -linkshared should be used. Is there an *up to date* tutorial in how to use them precisely? Is there some "bullet-proof" (or at least "newbie-proof") way to ensure that a given set of packages (in my current monimelt, it would include my packages objvalmo payloadmo serialmo and most importantly *all their dependencies*which includes, in addition of Go standard packages, jason <https://github.com/antonholmquist/jason/>, go-sqlite3 <https://github.com/mattn/go-sqlite3> (which sadly takes a *lot* of time to be compiled, because it does not use the system's *libsqlite3*, but recompile its own Sqlite amalgamation in C code), & rbt <https://github.com/ocdogan/rbt> .... And I expect to use more external libraries in the future. So how to force Go to systematically use -buildmode=shared? Is there some comment directive for that? Or should I provide my own shell script to build (I do know that the current one build-monimelt.sh <https://github.com/bstarynk/monimelt/blob/master/build-monimelt.sh> is very buggy). Is -buildmode=pie useful for me (I believe that not)? I'm sorry for still being a newbie regarding Go. I understand that my use case is not usual. I have very hard time understanding the precise relation between Go source files and Go packages and their build procedure (notably for plugins). Any link to a white paper describing them (in details) is welcome. The documentation of -buildmode <https://golang.org/cmd/go/#hdr-Description_of_build_modes> is not precise enough (and does not gives hints of which one to choose). The documentation of -linkshared <https://golang.org/cmd/go/#hdr-Compile_packages_and_dependencies> is saying just: -linkshared > link against shared libraries previously created with > -buildmode=shared. > > and I find that explanation too short (what happens if by mistake a previous package was compiled twice, both with -buildmode=shared & -buildmode=default and what happens if two weeks ago I have compiled my purple package -in some *older* version- with -buildmode=default and today I am compiling it -an *improved* version- with -buildmode=shared) ? Regards -- Basile Starynkevitch <http://starynkevitch.net/Basile/> (France) - email bas...@starynkevitch.net -- 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. For more options, visit https://groups.google.com/d/optout.
