On Fri, Jul 18, 2008 at 7:42 PM, Brian Dessent <brian@xxxxxxxxxxx> 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@xxxxxxxxx>
