QPluginLoader fails when using "debug" config

[paradiza]

Hi,

I'm using Qt 4.2.1 on Debian (etch) and I try to build a few plugins to extend my app's functionality. The problem I have is that QPluginLoader won't load my plugin if I compile the plugin (and the app of course) with "CONFIG += debug". In this case a subsequent QPluginLoader::errorString() just returns "Unknown Error".

However, when I leave CONFIG blank or set it to "release" all works flawlessly. The same behaviour can be witnessed when I try the official example code "plugandpaint" - the static library is loaded by the application but the dynamic library isn't.

Due to this I think that this is not related to my code but to Qt in general. Any idea?


Regards

[jacek]

The first parameter of Q_EXPORT_PLUGIN2 macro must match the file name, so if there is "d" or "_debug" appended to plugin's name in debug mode, you have to make relevant change in your code.

[paradiza]

True, but I'm using a static name as TARGET in my pro file. Even if I would use the dynamic version (as plugandpaint does)...

contains(TEMPLATE,lib) {
   CONFIG(debug, debug|release) {
      mac:TARGET = $$member(TARGET, 0)_debug
      win32:TARGET = $$member(TARGET, 0)d
   }
}

contains(TEMPLATE,lib) {
   CONFIG(debug, debug|release) {
      mac:TARGET = $$member(TARGET, 0)_debug
      win32:TARGET = $$member(TARGET, 0)d
   }
}

To copy to clipboard, switch view to plain text mode 

... it would only be relevant for Windoze and Mac OS, right?

As I'm using this .pro file...

TEMPLATE = lib
CONFIG += plugin debug
HEADERS += plugin.h
SOURCES += plugin.cpp
DESTDIR = ../bin/plugins
TARGET = plugin

TEMPLATE = lib
CONFIG += plugin debug
HEADERS += plugin.h
SOURCES += plugin.cpp
DESTDIR = ../bin/plugins
TARGET = plugin

To copy to clipboard, switch view to plain text mode 

... my usage of Q_EXPORT_PLUGIN2(plugin, Plugin) should be correct I think.

para

[jacek]

... my usage of Q_EXPORT_PLUGIN2(plugin, Plugin) should be correct I think.

Yes, it should be OK in such situation.

Nevertheless you could try Q_EXPORT_PLUGIN2(plugin_debug, Plugin) and rename your plugin to libplugin_debug.so.

[paradiza]

I just tried it... doesn't work.

Have a look at examples/tools/plugandpaintplugins/extrafilters/extrafiltersplugin.cpp. Even Trolltech uses a fixed value as target name in Q_EXPORT_PLUGIN2 although they consider the other host operating systems in their .pro file (see first code sample above). As stated above, adding debug to their CONFIG won't work either. Can you reproduce that on your machine? Maybe that gives us a clue...

para

[paradiza]

From the Qt docs:

If you configure Qt to be built in both debug and release modes, but only build applications in release mode, you need to ensure that your plugins are also built in release mode. By default, if a debug build of Qt is available, plugins will only be built in debug mode. To force the plugins to be built in release mode, add the following line to the plugin's project file:
CONFIG += release
This will ensure that the plugin is compatible with the version of the library used in the application.

What do they mean with the first sentence? Does the behaviour depend on the way Qt itself was built? I'm using the Debian package and hence have no influence on that I mean, as long as I set the same CONFIG values for the plugin and the app it should work, right?

para

[jacek]

Have a look at examples/tools/plugandpaintplugins/extrafilters/extrafiltersplugin.cpp. Even Trolltech uses a fixed value as target name in Q_EXPORT_PLUGIN2 although they consider the other host operating systems in their .pro file (see first code sample above).

Maybe something changed in Qt 4.2, but Qt 4.1 was very picky about that first parameter.

As stated above, adding debug to their CONFIG won't work either. Can you reproduce that on your machine?

I've just rebuilt both plugandpaint application and extrafilterplugin in debug mode and it seems to work OK.

[jacek]

I mean, as long as I set the same CONFIG values for the plugin and the app it should work, right?

Right .

[paradiza]

Maybe something changed in Qt 4.2, but Qt 4.1 was very picky about that first parameter.

I've just rebuilt both plugandpaint application and extrafilterplugin in debug mode and it seems to work OK.

Which Qt version and which OS are you using? Do you see libpnp_extrafilters.so being listed in the plugin dialog?

Thanks

[jacek]

Which Qt version and which OS are you using?

Qt 4.2.2 under PLD Linux.

Do you see libpnp_extrafilters.so being listed in the plugin dialog?

Yes and I can use those filters.

Did you add CONFIG += debug in extrafilters.pro or in plugandpaintplugins.pro (I did in the first one)?

[paradiza]

I set it in

1. basictools.pro (added "debug")
2. extrafilters.pro (added "debug")
3. plugandpaint.pro (added "CONFIG += debug")

Didn't you change plugandpaint.pro?

[wysota]

Make sure that all components are built either in debug or release modes. Qt, plugin and your app should all be linked against each other (specifically the plugin should be built against the same version (debug or release) of Qt libraries). If in doubt, use ldd to check if the application and the plugin are linked against the same files when it comes to Qt dependency.

[jacek]

Didn't you change plugandpaint.pro?

Yes I did.

I've built my Qt version in debug_and_release mode --- maybe that's why it works on my system?

[paradiza]

Possibly. In this case the Qt docs would make more sense to me but I still wouldn't understand Trolltech for creating a dependency to the Qt build process itself!
Can one determine how a given Qt installation was build...?

On the other hand it still seems to me that this is unrelated to my problem as the configure option appears to be applicable for Mac OS only:

-debug-and-release . Compile and link two versions of Qt, with and without debugging turned on. [Mac only]

Maybe it's time for an official bug report to clarify this...?

para

[paradiza]

Make sure that all components are built either in debug or release modes. Qt, plugin and your app should all be linked against each other (specifically the plugin should be built against the same version (debug or release) of Qt libraries). If in doubt, use ldd to check if the application and the plugin are linked against the same files when it comes to Qt dependency.

So you confirm what jacek says: if my Qt installation was built with "-release" instead of "-debug-and-release" there will never be a chance to compile my app and its plugins in debug mode because the Qt libs are not available for that mode, right?

How could they design such a dependency? I understand that the plugin verification needs to ensure that app and plugin have to be compiled the same way, but it should not care about Qt itself in my opinion...

para

[paradiza]

Ok, now I followed wysota's advice. The Qt debugging symbols are installed of course which means that, if I take libQtCore.so as an example, I have these to versions on my machine:

• libQtCore.so.4.2.1
• libQtCore.so.4.2.1.debug

No my (possibly silly) question: how to tell Qt to link against the .debug version when I compile my project using the debug flag? ldd shows that the release versions are still being used which explains the issue here...

Thanks

[wysota]

How could they design such a dependency?

In this case "they" is people who designed the dynamic linker in your system.

I understand that the plugin verification needs to ensure that app and plugin have to be compiled the same way, but it should not care about Qt itself in my opinion...

It's not about plugin verification. If you link your app against release version of Qt and the plugin against a debug version of Qt then you'd end up with linking two different Qt libraries (or sets of libraries) with the application. As the release and debug versions expose the same symbols, you'd end up with a relocation error because all Qt symbols would be defined in two copies. That's why the linker will deny dlopening such a dynamic dependency. So it's not Qt that enforces the limitation but the design of how dynamic linkers work.

No my (possibly silly) question: how to tell Qt to link against the .debug version when I compile my project using the debug flag?

The ".debug" file is not a library, it's just a set of symbols that are loaded when using a debugger. I don't know exactly how this works, but probably there are some differences between a file that has its ".debug" shadow and one that doesn't (at least such libs differ, so I guess there is a reason for that).

[paradiza]

Well, thinking a bit more about the linker system I agree with you

If you link your app against release version of Qt and the plugin against a debug version of Qt then you'd end up with linking two different Qt libraries (or sets of libraries) with the application.

True, but this is not what I do. I link both parts (app and plugin) against the same version of Qt. The problem is that I don't know whether it was built using "-debug-and-release". Any idea how this can be solved?

Regards

[jacek]

On the other hand it still seems to me that this is unrelated to my problem as the configure option appears to be applicable for Mac OS only

Mac only? I must be blind So it seems that my Qt was built in release mode after all.

I've just checked configure's options on windows and -debug-and-release is available there too, so certainly it's not "Mac only".

[paradiza]

Interesting, that's what configure -help shows...
Anyway, it seems that I've to find out how the Debian package maintainers built Qt and/or how this is going to work in conjunction with proper plugin development.

Thanks so far guys! I'll let you know any progress but please don't hesitate to post more ideas here

Bye