[Ctk-developers] Linking a shared library within a plugin

Tue Aug 27 07:59:08 UTC 2013

Hi Sascha,
we've figured out, that the tracker library uses another library for the
initialization of the connection. The problem was, that the symbols of this
library couldn't be resolved. This leads to the assumption, that the plugin
framework links correctly to a shared library, but not to shared libraries,
that are used by the first shared library.
By loading the tracker library with your
suggestion (ExportExternalSymbolsHint), it was possible to initialize our
tracker correctly! Thank you very much for your help!

For people with the same problem, this is the code to load a class from a
shared library which depends on other shared libraries (from a ctk plugin):

QLibrary library("library.so");
library.setLoadHints(QLibrary::ExportExternalSymbolsHint);
library.load();
if(library.isLoaded()){
    MyClass * c = new MyClass;
    if(c){
       // dostuff
    }
}

and for a function:

QLibrary myLib("library.so");
library.setLoadHints(QLibrary::ExportExternalSymbolsHint);
library.load();
typedef void (*MyPrototype)();
MyPrototype myFunction = (MyPrototype) myLib.resolve("mysymbol");
if (myFunction)
    myFunction();

Note, that you have to link your library.so also in the CMakeLists.txt with
target_link_libraries.

Best regards,
Florian

2013/8/26 Sascha Zelzer <s.zelzer at dkfz-heidelberg.de>

>  Hi Florian,
>
> this all sound really strange...
>
> as you have noted already yourself, plug-ins are also just shared
> libraries, which are loaded dynamically at runtime. If I understood you
> right, in the case of linking the proprietary tracker library to the
> plug-in, the plug-in starts successfully but the tracker library reports a
> runtime error. Is that correct?
>
> The only difference of which I can think of (compared to the working cases
> you mentioned), is that the plug-in is loaded via "dlopen" (on POSIX
> systems) using the QLibrary class. Depending on the Plugin Framework options
>
>
> http://www.commontk.org/docs/html/structctkPluginConstants.html#a29af0cac606ca29ea8d66d342d05060e
>
> different load hints are passed to QLibrary (
> http://qt-project.org/doc/qt-4.8/qlibrary.html#loadHints-prop). These
> load hints might affect symbol resolutions of subsequently loaded
> libraries, like your tracker library.
>
> But if all this really relates to your actual problem is not clear to me,
> sorry.
>
> Best,
>
> Sascha
>
>
>
> On 08/26/2013 02:37 PM, Florian Ganglberger wrote:
>
> Hi Jc,
> we've built a new shared library which calls our shared-tracker-library.
> It works perfectly outside of our plugin and the tracker can connect. As
> soon as we link the new shared library into the plugin, we have our
> connection problem again. It calls the function, produces all the output,
> but can't connect. So we can say that the* shared tracker library works
> for:*
> *- a normal example program*:   example program --> shared tracker library
> *- the main method of our ctk app:*   ctk app --> shared tracker library
> *- called from a "normal" shared library: *   example program -->
> "normal" shared library  --> shared tracker library
>
>  *and not for:*
> *- the plugin* (which is a shared library): ctk plugin --> shared tracker
> library
> *- a call from a shared library which is called by the plugin*:  ctk
> plugin --> "normal" shared library  --> shared tracker library
>
>  Actually we have no idea, why it doesn't work....
>
>  Thanks for your help,
> Florian
>
>
>
> 2013/8/26 Florian Ganglberger <Florian.Ganglberger at student.i-med.ac.at>
>
>> Hi Jc,
>> we can't really use a debugger, since we don't have the code for the
>> shared library, only the header files. The methods of the shared library is
>> definitely called, because we get an error message that a connection to the
>> tracker can't be established. Can it be a problem, that the plugins are
>> also shared libraries? We'll write a shared library that calls the tracker
>> today, so we can see if the problem depends on calling the tracker-library
>> from a shared library or if it is ctk specific.
>>
>> Additional information: As far as we know, the tracker library was
>> written in C (and not in C++)
>>
>>  Thanks for your help,
>> Florian
>>
>>
>>  2013/8/24 Jean-Christophe Fillion-Robin <jchris.fillionr at kitware.com>
>>
>>> Hi Florian,
>>> If it build without problem, did you try using a debugger to try to
>>> understand what s wrong?
>>> Jc
>>>
>>> --
>>> Sent from my mobile device
>>>  On Aug 23, 2013 12:00 PM, "Florian Ganglberger" <
>>> Florian.Ganglberger at student.i-med.ac.at> wrote:
>>>
>>>>  Hi,
>>>> we are trying to link a shared library to connect to tracker from a
>>>> plugin. We know, that the code that calls the .so library works in a test
>>>> application and also in the main method of our CTK application. After we
>>>> have added our code to the plugin and linked it to the .so library, we can
>>>> link and compile the code without errors, but we don't get a connection to
>>>> the tracker.
>>>> The cmakelists code to link the .so file in our test application is
>>>> TARGET_LINK_LIBRARIES(optoExtern ${OPTOTRAK_LIBRARY})
>>>> (${OPTOTRAK_LIBRARY} is the library path, optoExtern the project name)
>>>>
>>>>  The cmakelists code to link the .so file in our plugin:
>>>>  ctkMacroBuildPlugin(
>>>>   NAME ${PROJECT_NAME}
>>>>   EXPORT_DIRECTIVE ${PLUGIN_export_directive}
>>>>   SRCS ${PLUGIN_SRCS}
>>>>   MOC_SRCS ${PLUGIN_MOC_SRCS}
>>>>   UI_FORMS ${PLUGIN_UI_FORMS}
>>>>   INCLUDE_DIRECTORIES ${Plugin_SOURCE_DIR}
>>>>   RESOURCES ${PLUGIN_resources}
>>>>   TARGET_LIBRARIES ${PLUGIN_target_libraries} ${OPTOTRAK_LIBRARY}
>>>> )
>>>>
>>>>  Has anyone an idea how to link external shared libraries within a
>>>> plugin properly?
>>>>
>>>>  Best regards,
>>>> Florian Ganglberger
>>>>
>>>>  _______________________________________________
>>>> Ctk-developers mailing list
>>>> Ctk-developers at commontk.org
>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>>>
>>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20130827/b66534bd/attachment.htm>