[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Shared library runtime loading and C++ classes

From: Francois Goudal
Subject: Shared library runtime loading and C++ classes
Date: Wed, 08 Dec 2010 15:42:26 -0000
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv: Gecko/20100802 Thunderbird/3.1.2


I'm currently trying to write a plugin system for my C++ project.

I have been reading the C++-dlopen-mini-HOWTO and now I'm trying to implement it in my own project. But there are some particularities in my project which makes it more difficult and I'm a bit blocked right now with dynamic linking issues :

For the plugins, I have defined a virtual class called CConfigPlugin, and right now I have a test plugin class called CTestConfigPlugin which inherits from the CConfigPlugin and implements all the virtual methods.

Also, together with the CTestConfigPlugin, I have a static "C" function called get() which creates an instance of CTestConfigPlugin and returns a pointer to it.

This CTestConfigPlugin class together with the static "C" function get() are compiled using g++ and linked to a shared library, so I have a file

The goal is that my main program will dlopen this file and run dlsym to find the get() symbol and call it in order to get an instance of CTestConfigPlugin which it will be able to call methods through the CConfigPlugin interface class.

All this is exactly like in the howto, now I have a difference though :

My main program contains a singleton class called CConfigController which I can get through the method Instance().

I need my plugins to be able to get the instance of this class and run some methods of it.

As a consequence, the code of the Test plugin is calling CConfigController::Instance(). The configcontroller.cpp file is linked with my main program, and as a matter of fact :
$ objdump -t a.out  | grep ConfigController
0804a881 l F .text 0000001c _GLOBAL__I__ZN7mytest17CConfigController8InstanceEv 0804e6a8 g F .text 000000d7 _ZN7mytest17CConfigController8InstanceEv

I would have hoped that when dlopen would load my, which requires the symbol _ZN7mytest17CConfigController8InstanceEv would find it automatically in the main program, but obviously it doesn't work that way :

In the main program, dlopen fails, and dlerror returns that string :
/u/fg/ undefined symbol: _ZN7avioipd17CConfigController8InstanceEv

I also have tried to link configcontroller.cpp together with the testconfigplugin.cpp into the .so, but it doesn't help (and anyway, that would potentially conflicts since loading the .so would lead to 2 symbols with the same name being there since the symbol already exists in the main program).

Am I trying to do something impossible, or could somebody give me a hint on how I can make this work ?

Thank's in advance

Francois Goudal

reply via email to

[Prev in Thread] Current Thread [Next in Thread]