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
