Problem linking to wrong class

John (Eljay) Love-Jensen eljay@adobe.com
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 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



More information about the Gcc-help mailing list