Problem linking to wrong class

John (Eljay) Love-Jensen
Mon Apr 20 19:04:00 GMT 2009

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

My guess is that the 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

One way around the issue is called ³early binding².  You could build such that it binds to its own symbols, rather than allowing the
loader to resolve the unbound symbols with the ones provided by your

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


More information about the Gcc-help mailing list