Question

I’m on Linux, the question is concerning shared objects of C++ classes.

The problem comes when my shared objects try to use resources linked into the main executable. I have the following codes:

loader.cpp:

#include <dlfcn.h>
#include <iostream>
#include "CommonInfo.h"

using namespace std;

int main(int argc, char** argv) {
    for(int i=1; i<argc; ++i) {
        string pth = "./";
        pth.append(argv[i]);
        void* dh = dlopen(pth.c_str(), RTLD_NOW);
        if(dh==NULL) {
            cerr << dlerror() << endl;
            return 1;
        }

        CommonInfo::GetInfoFunc getInfo = (CommonInfo::GetInfoFunc)(dlsym(dh,"getInfo"));
        if(getInfo==NULL) {
            cerr << dlerror() << endl;
            return 1;
        }

        CommonInfo* info = getInfo();
        cout << "INFO: " << info->getX() << endl;
        delete info;
    }
    return 0;
}

CommonInfo.h:

#include <string>

class CommonInfo {
    public:
        typedef CommonInfo* (*GetInfoFunc)();
    private:
        std::string x;
    public:
        CommonInfo(const std::string& nx);
        std::string getX() const;
};

EDIT:
I accidentaly forgot to ctrl-c + ctrl-v the source of CommonInfo.cpp here. Of course, it is there during compilation, so CommonInfo.cpp:

#include "CommonInfo.h"

CommonInfo::CommonInfo(const std::string& nx) : x(nx) {
}

std::string CommonInfo::getX() const {
    return x;
}

A Plugin.h header:

#include "CommonInfo.h"
extern "C" CommonInfo* getInfo();

A very simple Plugin.cpp:

#include <iostream>
#include "Plugin.h"
#include "CommonInfo.h"

using namespace std;

CommonInfo* getInfo() {
    return new CommonInfo("I'm a cat!");
}

Compiling is done with:

g++ -rdynamic -ldl -Werror CommonInfo.cpp loader.cpp -o loader
g++ -shared -fPIC -Werror Plugin.cpp -o Plugin.so

Running:

./loader Plugin.so

And there goes the error:

./loader: symbol lookup error: ./Plugin.so: undefined symbol: _ZN10CommonInfoC1ERKSs

Indeed, looking inside Plugin.so with nm Plugin.so | grep -i CommonInfo it gives an ‘U’ for this symbol (unresolved), which is perfectly ok.
Also, looking inside the binary of loader with nm loader.so | grep -i CommonInfo I could find the symbol with ‘T’, which is also ok.
Question is, shouldn’t dlfcn.h unresolve the symbol in question from the main binary? Without this feature it becomes quite hard to use these stuff… Do I have to write a class factory function for CommonInfo, load it with dlfcn from the plugin and call that?

Thanks in advance,
Dennis

Answer 1

I haven’t looked closely at your code, but I have in the past found behavior like you describe in the title when I did not link the executable with -E. (Or -Wl,-E when linking with gcc rather than ld.)

Note that not all platforms let the shared libraries take symbols from the calling binary. Linux and the *BSDs allow you to. But if you ever want to port to, say, Windows, you will not be able to use this pattern. I believe there are also some Unix-type OS’s that won’t let you do this. (It’s been a while so I don’t remember… Maybe it was Solaris?)