Hello All, This *package, files at build (in relation to plugins, -linkshared, -buildmode=shared, ....)* thread <http://package, files at build (in relation to plugins, -linkshared, -buildmode=shared, ....)>, and that *plugins (Go 1.8) and packages* one <https://groups.google.com/forum/#!topic/golang-nuts/IKh1BqrNoxI>, and the older *"multiple roots" error with 'go install buildmode=shared'* one <https://groups.google.com/forum/#!msg/golang-nuts/PLlAZM7AfOI/37H2E0vPe2UJ> (by Aaron Beitch)
The context In my monimelt <https://github.com/bstarynk/monimelt> project on github (for Linux x86-64 with Go 1.8), I want to generate Go code at runtime, for the Go compiler at runtime, and load it as plugins (all that in the same process; I did that in GCC MELT <http://gcc-melt.org/> for C++ code). Ideally (I am very far from that) I would like it to become a bootstrapped compiler <https://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29> of some language (I am inventing) with my compiler (or transpiler) generating Go code. Ideally (I am very far from that), it would become (also) a Quine <https://en.wikipedia.org/wiki/Quine_%28computing%29> prorgram. The first step would be to store in some (Sqlite3) database something translatable to several plugin code. So I would like to have: a main program P0 able to load many objects from Sqlite3; I believe I already have it. an ordered sequence of plugins, P1, P2, ... Pn where all plugins (actually their Go code is generated at runtime) can import some packages provided by the main program P0, plugin P2 can also use, ie import, some package provided by plugin P1, plugin P3 can also use, i.e. import, packages from P1 and from P2, and plugin Pi can use packages from any Pj with j < i. So I need most of the code to be shareable. In an ideal world, I would like to forbid static unshared code in all my Go installation. I know that this is against the default rules of Go (which sadly prefers static linking; but recent Go fortunately have -buildmode=shared and -linkshared options to overcome that; I will use them *systematically*). So I understood that I first need (once and for all after a pristine Go installation) to run go install -buildmode=shared std and I know how to check that it has been run. Then, every other package (either an external one, like go-sqlite3, or mine) that I will compile needs to be compiled with both -buildmode=shared and -linkshared options. Cryptic *multiple roots* error I quite often get the *cryptic * multiple roots /home/basile/go/pkg/linux_amd64 & /usr/local/go/pkg/ linux_amd64 message (I believe *that message is very confusing* and would merit an entire wikipage to explain it; I also believe that the error message itself should be improved to suggest corrective actions) For what it is worth, /home/basile/go is my default GOPATH, and /usr/local/go is my default GOROOT. And I am getting that message depending on past history of previous commands. So to debug it, I quite often remove all my Go subsystem (by running rm -rf $HOME/go /usr/local/go then improving my $PATH, or adding there appropriate symlinks for the go, gofmt, godoc programs to e.g. /usr/local/bin which is in my $PATH), reinstall it, and repeat.... and that is *very* time consuming. Ian Taylor kindly explained me that multiple roots is about: That error message means that the go tool does not know where to > install a file. It may mean that you are trying to use > -buildmode=shared with some standard library packages and some > packages from your GOPATH. It's not a conflict between different > files; it's talking about which directory it should put the shared > library in > But I don't understand how to avoid it. Is there some option or some way to say to Go that I want the binary package to be written under GOPATH and not under GOROOT; or to force the subtree in which there are written. A simplified way to ask my questions I believe I can ask my question in a simpler way. Imagine that I am inventing the oG language: An oG source file foo.og is translated to Go (file foo.go) by exchanging upper and lower cases letters, so the oG source file // file foo.og PACKAGE PINK IMPORT ( "FMT" ) FUNC pINKFLOYDS(S STRING) { FMT.pRINTF("IN pINKFLOYS S=%V\N", S) } is (trivially) translated to this Go file // FILE FOO.OG package pink import ( "fmt" ) func Pinkfloyds(s string) { fmt.Printf("in Pinkfloyds s=%v\n", s) } and we are all able to code in Go the trivial Og to Go compiler (just translate uppercase to lowercase and vice-versa) I think my question can be paraphrased as: Write the Og compiler (compiled into command og) in Go, so that when running og /tmp/pink/ /tmp/blue/ the following things are happening in turn: - every .og file in /tmp/pink/ directory, e.g. /tmp/pink/pink1.og /tmp/pink/pink2.og is trivially translated to its .go file pink1.go & pink2.go (that file can be in whatever directory is the most convenient), and all these files are defining some package pink (e.g. with some public function pink.PinkFoo) and they can use standard Go functions or some existing functions and packages in og. - a pink.so plugin is compiled from them. it is loaded by a call to plugin.Open <https://tip.golang.org/pkg/plugin/>. - every .og file in /tmp/blue/ directory, e.g. /tmp/blue/blue1.og & /tmp/blue/blue2.og is trivially translated to blue1.go & blue2.go ; notice that blue2.go has a line import "pink" and is calling pink.PinkFoo function from a blue.BluePublic function. - a blue.so plugin is compiled from them. It is loaded (by the main program og). The blue.BluePublic function is looked up with plugin.Lookup and executed. I am able to write the trivial Og to Go compiler. What I don't understand is what exact commands should be run (notably what go compilation commands should og run). *I'm struggling since more than a month to understand that*, so *I really need some help*. Thanks for reading. Could someone explain how I can code that? (and how to avoid the *multiple roots* message). What would be the prefered place of the generated blue1.go etc... (In monimelt, the Og source files are extracted and computed from some Sqlite database, but that is an implementation detail I can master). So both monimelt and the generated pink & blue are also using go-sqlite3 and other packages. Cheers. Basile Starynkevitch <http://starynkevitch.net/Basile/> (France) basile at starynkevitch dot 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
