Functions with the same name being called in different libraries (not exported): Wrong one gets called in main program

[Marc Glisse]

On Fri, 24 Aug 2012, Philipp Schmidt wrote:

> Hi,
>
> I have multiple classes that I need to hide some functionality. Said
> functionality is in part provided by code that is being generated from files
> outside of my control. Since they provide different services that all utilize
> a specified format many class and function names are the same and even have
> the same interface. Yes, the best solution would be to resolve that, but sadly
> that is not possible. So I somehow have to work around that.
>
> In order to seperate them I put them all in seperate shared libraries. So now
> I have some libraries, libA, libB etc. that have nonambiguous interfaces.
> In the implementation file (not the header) each library includes the
> according header files from the generated code and operates on data calling
> the generated functions. So nothing is visible to the outside and they all
> compile fine.
>
> In the main program (successfully linked against all libraries) I now generate
> classes from them. Now the call to a function from the libA-class that uses
> the foo()-function from the generated code for libA works as expected, but
> when getting to the function in libB that calls the foo() function from the
> generated code for libB it segfaults. The backtrace revealed that the class
> from libB actually tries to call the foo()-function from libA, where of course
> some symbols are different. So far so logical.
>
> But how can I get my code to work so that the foo() function used in libB is
> actually the one that I included and compiled into libB? Can I somehow tell
> the gcc linker to first look in the library code where the function is being
> executed?

Depending on what exactly you can change, you may be interested in 
-fvisibility (or #pragma gcc visibility), or linker maps/scripts.

-- 
Marc Glisse