Jef Driesen wrote: > And how about gcc < 4.0 that do not support the visibility attributes? > Is there a way to hide non-public symbols? Is the version script still > available in this case? Is it possible to use both the attributes and > the -export-symbols together?
There are two aspects to the symbol visibility stuff: A) When the compiler knows at compile time that a function or variable has hidden visibility it can create more efficient code for calling/accessing it because it doesn't have to use the usual PIC indirection through the PLT/GOT. This is similar to how marking a function static allows the compiler more latitude to optimize it, except this also works for functions that must remain accessible from other objects in the library but not accessible from outside the library. B) When linking the shared library, it's helpful to reduce the number of entries in the dynamic symbol table to only those that are part of the defined public API. This is what improves the symbol lookup time during startup, as well as ensuring that no client of your library accidently uses some undocumented or internal interface. When you use __attribute__((visibility)) you get both (A) and (B), but when you use a version map you get (B) only. However, since (B) only happens at link-time it doesn't require any compiler support and it only depends on whether the linker supports symbol versioning. I believe that libtool is smart enough to check the linker for symbol versioning support to implement -export-symbols, so as long as you are using a non-ancient version of binutils it should work fine with gcc < 4 and still provide the (B) benefits. Brian
