visibility and -Wl,--version-script

[Brian Dessent]

Mathieu Lacage wrote:

> g++ -L. -ltest -o maintest maintest.o

It's not related to your issue, but this is wrong.  The order that you
specify things on the link command line matters, and -ltest needs to
come after objects that reference symbols in libtest.so.  In your
specific situation you can get away with it, but not in other situations
such as if -ltest was a static archive, or with shared libraries on
non-Linux systems.

> The question, then, is whether or not what I am trying to do is
> possible without having to define a large set of symbol aliases (I am
> not even sure how to define a set of aliases for a class) which define
> different visibility attributes for the original symbol and for the
> alias symbol. The crux of the issue here is that what I am trying to
> do is to make my library not use the GOT/PLT for any internal function
> calls but to allow client programs to access all of the libraries'
> public functions through the GOT/PLT. I understand that what I want to
> do is likely to break some of the fine print of the C++ standard but,
> I think I can live with that so, is there a way to do this ?

You've read <http://people.redhat.com/drepper/dsohowto.pdf>, correct?

You're confusing two things.  The version script can cause the linker to
hide or expose symbols from the symbol table, but it does not alter
their visibility.  Your Test::Do() and A() are still hidden and thus
can't be exported as dynamic symbols.

If you want to use -fvisibility=hidden you need to arrange for default
visibility for those symbols that you do want to export with
__attribute__ ((visibility("default"))) or using #pragma GCC visibility
push/pop.

But if you simply want to avoid PLT/GOT overhead for symbols not
exported, why not just make those functions/variables static?  It has
the same effect, and works with any compiler including gcc < 4.x which
didn't have -fvisibility.  Of course this doesn't apply if you need to
access the internal symbols from another object in the same library.

Brian