How to control the symbol visibility of shared lib built from Go

[Song Liu]

Hi,

I am going to write a shared library using the Go, you know that the Go runtime and used libraries are compiled into the library together.

But it seems that all the symbols from this library is "DEFAULT", is there a way to use the "HIDDEN" symbol visibility by default, but "DEFAULT" only for the API exposed by this library.

This is could be done in c/c++ via. the "__attribute__(visibility(default))" and "-fvisiblity=hidden", what will do in CGO ?

Thanks,

Song

[Ian Lance Taylor]

No, this is not currently available in Go.

It's not clear to me that anybody would actually want this, as having
multiple copies of a hidden symbol would then to break things.

Ian

[Song Liu]

Default symbol could break loading multiple shared lib implemented by different version of go runtime,

if there is one symbol with same name but with different logic.

And, the shared lib implemented by Go has too many symbols from the Go runtine and libraries, which will result in the loading performance.

[Konstantin Khomoutov]

On Mon, 20 Mar 2017 23:21:20 -0700 (PDT)
Song Liu <song...@gmail.com> wrote:

> Default symbol could break loading multiple shared lib implemented by
> different version of go runtime, if there is one symbol with same
> name but with different logic.

This actually means they won't be compatible neither with the Go
runtime which loaded them nor with one another, does it?

I mean, suppose that both shared modules refer to, say, runtime.Foo
but expect it to have "different logic". But there's only the single Go
runtime in play here -- the one which loaded both modules -- there's
just "one" logic provided by runtime.Foo. It may match the
expectations of the first module, the second, both or none. I'd say, a
sensible assumption is that both modules and the runtime itself must
agree on what logic is expected/provided.

IOW, all the code working on the runtime must have the same idea about
all the shared code it provides.

> And, the shared lib implemented by Go has too many symbols from the
> Go runtine and libraries, which will result in the loading
> performance.

[...]

[David Collier-Brown]

Hidden isn't used by Go at this time, but if it's part of the elf tradition, then the term probably refers to the same thing that Sunw_PRIVATE did on Solaris: this symbol can only be used within the library, not by anyone outside it.

It's a tiny bit of a kludge: we didn't realize we needed a "binder"[1]  to remove symbols we didn't want visible, so we declared them private and complained when they were used by anything other than a system library.

Were you thinking of this kind of use, or did you have soemthing else in mind? 

--dave

[1. http://multicians.org/mgb.html]

[Song Liu]

Yes.

1. "default" visibility will contribute the loading time.

2. also it's possible to relocate the symbol provided by another linked library.

but if it's protected or hidden these symbols won't be relocated anymore during loading.