When you're writing a shared library, it's usually recommended to hide all internal symbols to reduce dynamic linking time, normally using a linker script or -fvisibility option.
In my case, the shared library is linked with two types of other libraries:
All of them are linked into the shared library using the -Wl,--whole-archive option, so that the resulting shared library is self-sufficient and links only to stdlib.
All symbols from internal static libraries are hidden, because they're not a part of the public API.
The question is what are pros and cons of hiding the symbols from third-party static libraries? Are there any best practices and known pitfalls? In one hand, they're not a part of the public API of my library. In the other hand, they're part of the public API of third-party libraries.
I guess problems arise when the user wants to link to another version of the same third-party library. Hiding its symbols theoretically may solve them, but it feels that in practice it may lead to some new unexpected problems.
In my opinion you should hide all symbols that are not part of your API. It seems also that you will need an option --exclude-libs,ALL to convert third party static library symbols to hidden ones. I don't know any cons of the solution, it speeds up dynamic linker, also don't see any drawbacks for further static linking with another library version.. because its static linking not dynamic linking (hot swapping or so).