Hi Brian, When you link against the static library, any missing symbols cause the providing ³.o² in the ³.a² static library to be linked into your executable. (There is a switch that links in the entire static library, not just the needed object files from the static library. Sometimes vitally useful, but usually should not be necessary.) When the loader resolves symbols, any visible symbols in your executable have preeminance over unbound symbols from ³.so² shared libraries. That means if, for example, you provide your own malloc routine, shared libaries which use malloc will use the malloc which your executable provides, not the malloc that is in the libc.so. My guess is that the libtwo.so is using the symbols linked into your executable that became part of your executable from libone.a. Those executable symbols are preferential, even over the self-same symbols in libtwo.so. One way around the issue is called ³early binding². You could build libtwo.so such that it binds to its own symbols, rather than allowing the loader to resolve the unbound symbols with the ones provided by your executable. Another way around the issue is by using unique namespaces, as you already found out. Yet another way around the issue is by using -fvisibility=hidden ... but that has its own caveats, such as needing to explicitly expose symbols that are intended to be visible outside of the ³package² (the ³.so² or the executable itself). The ³package² concept is not really part of core C++ proper, but you may have run into it with Python or Java or D other languages which provide language support for the notion of what constitutes a package. Visibility is one such packaging mechanism. Check the GCC documentation for attribute visibility. HTH, --Eljay
