Re: visibility and -Wl,--version-script

["Mathieu Lacage" <mathieu.lacage@gmail.com>]

On Fri, Jul 18, 2008 at 7:42 PM, Brian Dessent <brian@dessent.net> wrote:

>> 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?

yes.

>
> 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.

yes, the output of my test program clearly shows that my expectations
were indeed invalid.

> 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.

Right, but if I do that, gcc will use GOT/PLT lookups to access these
symbols even when doing accesses from within the library and that is
precisely what I would like to avoid.

> 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.

Yes.

Mathieu
-- 
Mathieu Lacage <mathieu.lacage@gmail.com>