On Thu, Sep 1, 2016 at 3:50 PM, Nadav Har'El <[email protected]> wrote: > > On Thu, Sep 1, 2016 at 10:40 PM, David Crawshaw <[email protected]> wrote: >> >> It sounds like you'll need to use external linking if you need >> runtime.tlsg to be TLS IE. Using c-shared is reasonable if you have >> some machinery to do the equivalent of dlopen and call the global >> initializer the runtime inserts into the c-shared library. >> >> Does OSv support the equivalent of dynamically loading a .so that uses >> TLS IE? If so, buildmode=c-shared is a good way to go. > > > Yes, exactly - OSv basically revolves around a dynamic linker which can > load ELF objects (shared object, PIE, etc.), link their references to glibc > to the implementation in the OSv kernel (and also allow resolving > references between different shared libraries, as usual) - and then run > the result. And TLS IE is supported. > > So yes, buildmode=c-shared indeed sounds like the best build mode for us. > It seems that buildmode=c-shared hides *all* the functions from the dynamic > linker, though, so I guess we'll need to "export" at least the main() > function. > > I wonder, by the way, why is exporting main() not the default? > How is c-shared usable without exporting anything?
Any function exported by cgo is exported in a c-shared library. https://golang.org/pkg/cmd/cgo/#hdr-C_references_to_Go So if you declare: package main import "C" func main() {} // never called in c-shared mode //export GoStart func GoStart() { // ... your program } Then your loader will be able to resolve "GoStart". > Nadav. -- You received this message because you are subscribed to the Google Groups "OSv Development" 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.
