Programming

I've got a C++ program and some plugins ( shared objects ) that I have been developing for Linux. I was originally using and OSX machine to develop and test most of the code.

I use dlopen to open the shared objects and then call methods from them. It behaves differently on Linux ( don't know the version right now, have to check tomorrow ) vs. OSX ( 10.6 ).

The plugins are the same class & methods exactly, except for a method that returns the plugin name ( see below ).

Code:

namespace plugin
{
class child : public parent
{
...
std::string pluginName()
{
   return "plugin1";
}
...
};
}

extern "C" void Init( plugin::pluginAPI *pApi )
{
   parent *parent = new child();
   pApi->plugin( parent );
}

namespace plugin
{
class child : public parent
{
...
std::string pluginName()
{
   return "plugin2";
}
...
};
}

extern "C" void Init( plugin::pluginAPI *pApi )
{
   parent *parent = new child();
   pApi->plugin( parent );
}

My main() does dlopen on each of them, finds an Init() method and calls the init method for each, passing a pointer to an api class so Init() can give main() back a handle to the plugin ( via the parent base ).

When main() calls parent->pluginName(), on OSX, it always returns "plugin1" no matter which handle is used. On Linux, the same code returns "plugin1" when that handle is used and "plugin2" when that handle is used.

Now, the OSX result seems correct to me, because that .so is loaded first, but I would still expect a dlopen error when loading the second one.

I know the proper solution is to have different child class names in each plugin - that is going to happen at some point, but I still would like to figure out why OSX and Linux behave differently in this regard.

I'm investigating this myself, but was wondering if someone can shed any light on this?

Regards,
RK

Could you post a more representative sample? That's not enough to compile and test and see what you're doing.

Did you declare the function as virtual? You shouldn't try and overload things that aren't.

Thanks for the reply.

Yes, the getName() is virtual in the common header.

I'll try to post a buildable example today, I was just pulling pieces out and reworking, because I can't post my exact code here.

-RK

This looks like a scoping issue. If the names of the two classes are identical, depending on the scope of your symbols at compile and link time, when your Init method creates a new object it can either use the methods from its own shared object or from the first one it finds in the symbol table.

Unless you want to always be chasing down weird issues like this from platform to platform and compiler to compiler and linker to linker, you do not want to depend on symbol scoping to make sure you call the correct method.

The easiest solution is to give each child class a distinct name.