On Sun, Feb 7, 2021 at 7:02 PM Frédéric De Jaeger
<fdejae...@novaquark.com> wrote:
>
> Hi, this is a followup of https://groups.google.com/g/golang-dev/c/J7W3sDexK18
> that I've mistakenly posted in the wrong channel. I feel ashamed about it.
No need to feel ashamed, it's an easy mistake to make, and a harmless one.
> Ian Lance Taylor wrotes:
>
> > This is a consequence of the fact that (on most systems) shared
> libraries share a symbol namespace, so that all references to, say,
> runtime.chansend are resolved to the same function. If different Go
> shared libraries built using -buildmode=c-shared are built with
> different versions of Go, then the fact that they call the same
> runtime.chansend function can mean that one of the shared libraries
> will not work correctly.
>
> Thanks for your quick response.
>
> When I build a package like this
>
> go build -work -buildmode c-shared -o pouet.so .
>
> I get a standalone .so that contains anything needed (business code + go
> runtime)
> The contract is that symbols like this:
>
> //export XPluginStart
> func XPluginStart(outName, outSig, outDesc *C.char) C.int {
>
> are exported and made visible to the outside world (the C based host programm
> that loads the .so)
>
>
> When I do:
>
> > nm pouet.so | grep " T "
>
> It gives many publicly visible go symbols
> 00000000000d75a0 T x_cgo_callers
> 00000000000d71d0 T x_cgo_init
> 00000000000d7380 T x_cgo_mmap
> 00000000000d73b0 T x_cgo_munmap
>
> and also mine:
>
> 00000000000d6be0 T XPluginStart
>
> My understanding of that is that you can control the visibility of symbols,
> can't you ?
>
> IMHO, all the other symbols (including everything from the runtime) could be
> hidden.
>
> > That's not how shared libraries work on many systems.
>
>
> I suppose I might be missing something. I'm not a total expert on that
> matter. Suppose we tune the visibility of symbols such that the previous
> command would only shows the ones I specifically want to be accessible to the
> C host. And everything else (runtime global variable, functions, ...) is
> made private (it appears with the symbol `t` instead of `T`). Wouldn't that
> guarantee that successive loading of plugin like these would all have their
> own copy of the runtime ?
>
> MacOS, linux, and windows all provide a way to control the symbols
> visibility. Were you talking about other systems where you can't control the
> symbol visibility so easily ?
>
> MacOS has his _two level namespace_ thingy. It is supposed to guarantee (if
> I understand that stuff correctly) that symbol resolution is done right, (if
> `a.dylib` calls `foo` that exists in `a.dylib` and also in another `b.dylib`,
> the one in `a.dylib` gets called) So what currently happens on MacOS ?
> Don't we have several runtime instantiated in this scenario ?
>
> I can imagine other traps on that road. Other form of global per process
> resources could cause issues. Signal, maybe ?
Thanks, you may be correct: it may be possible to hide all symbols
other than the ones that are intended to be exported to the C program.
If it is possible to do that reliably in all cases, then the effect
should be that if you link against multiple shared libraries, each
will have an independent Go runtime. The program will wind up with
different Go heaps and different garbage collectors competing with
each other. The result will be inefficient, sometimes alarmingly so,
but I don't immediately see any reason why it wouldn't work.
Ian
--
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/CAOyqgcULKmGGuV-82AW8NrN7dUstCWZZ%3Duces7Kvma7-gkxNyw%40mail.gmail.com.
