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.
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 ?
Fred
--
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/dc5f138d-9512-4ce4-9727-8b55c79fa3bbn%40googlegroups.com.
