Qt-interest Archive, January 2008
[Win32] Plugin fails silently - how to debug ?
Message 1 in thread
1. I am using Qt 4.3.2.
2. I have a plugin that builds and links both in Win32 and Linux.
The plugin code, and the code to load and use it, is identical in
both environments. I'm building with VS2005 under Win32.
3. I have code that loads and uses the plugin correctly in
Linux. The same code fails to load the plugin in Win32.
I have code like this:
> if (MDP::TransferrerInterface *interface = qobject_cast<MDP::TransferrerInterface *>(loader.instance()) )
> {
and the branch is never taken under Win32.
Also QPluginLoader::isLoaded() returns false at this point.
4. I've set QT_DEBUG_PLUGINS but this produces no o/p.
5. The QPluginLoader::errorString() method returns "unknown error"
in Win32.
6. The plugin has been built with the same compile options
as the executable that tries to load it.
Can anyone suggest how I can track down the problem ?
I seem to have run out of ideas.
--
[ signature omitted ]
Message 2 in thread
On fredag den 4. Januar 2008, Stephen Collyer wrote:
> 1. I am using Qt 4.3.2.
>
> 2. I have a plugin that builds and links both in Win32 and Linux.
> The plugin code, and the code to load and use it, is identical in
> both environments. I'm building with VS2005 under Win32.
>
> 3. I have code that loads and uses the plugin correctly in
> Linux. The same code fails to load the plugin in Win32.
>
> I have code like this:
> > if (MDP::TransferrerInterface *interface =
> > qobject_cast<MDP::TransferrerInterface *>(loader.instance()) ) {
>
> and the branch is never taken under Win32.
>
> Also QPluginLoader::isLoaded() returns false at this point.
>
> 4. I've set QT_DEBUG_PLUGINS but this produces no o/p.
>
> 5. The QPluginLoader::errorString() method returns "unknown error"
> in Win32.
>
> 6. The plugin has been built with the same compile options
> as the executable that tries to load it.
>
> Can anyone suggest how I can track down the problem ?
> I seem to have run out of ideas.
When all else fails with plugin loading, I singlestep through the qt plugin
loader code. It's the only way to really figure it out.
One thing, though: Make sure your application, plugin and Qt is built with the
same setting. If one of them is a debug and another a release build, it won't
load the plugins. This is one of the things that are fairly easy to spot when
singlestepping through the qt code.
Bo.
--
[ signature omitted ]
Message 3 in thread
Bo Thorsen wrote:
> When all else fails with plugin loading, I singlestep through the qt plugin
> loader code. It's the only way to really figure it out.
Yes, I started doing this. Pretty useful.
> One thing, though: Make sure your application, plugin and Qt is built with the
> same setting. If one of them is a debug and another a release build, it won't
> load the plugins. This is one of the things that are fairly easy to spot when
> singlestepping through the qt code.
Right. This is what seems to have happened - I can't see how at the
moment though. I did indeed discover this when stepping through the
Qt code.
--
[ signature omitted ]
Message 4 in thread
Stephen Collyer wrote:
>> One thing, though: Make sure your application, plugin and Qt is built with the
>> same setting. If one of them is a debug and another a release build, it won't
>> load the plugins. This is one of the things that are fairly easy to spot when
>> singlestepping through the qt code.
>
> Right. This is what seems to have happened - I can't see how at the
> moment though. I did indeed discover this when stepping through the
> Qt code.
OK, I've solved the problem. I'm using CMake and had stolen
the required defines from the CMake wiki. These build a
release plugin:
ADD_DEFINITIONS(${QT_DEFINITIONS})
ADD_DEFINITIONS(-DQT_PLUGIN)
ADD_DEFINITIONS(-DQT_NO_DEBUG)
ADD_DEFINITIONS(-DQT_SHARED)
and it seems that QT_NO_DEBUG forces the plugin to be built
in release mode. I've removed this and rebuilt and the plugin
loads and runs correctly in Win32.
However, I can't find much info on what QT_NO_DEBUG does -
can anyone explain how this forces a release mode build.
I'm not sure what the mechanism is.
--
[ signature omitted ]
Message 5 in thread
Stephen Collyer wrote:
> Stephen Collyer wrote:
>
>
>>> One thing, though: Make sure your application, plugin and Qt is built with the
>>> same setting. If one of them is a debug and another a release build, it won't
>>> load the plugins. This is one of the things that are fairly easy to spot when
>>> singlestepping through the qt code.
>>>
>> Right. This is what seems to have happened - I can't see how at the
>> moment though. I did indeed discover this when stepping through the
>> Qt code.
>>
>
> OK, I've solved the problem. I'm using CMake and had stolen
> the required defines from the CMake wiki. These build a
> release plugin:
>
> ADD_DEFINITIONS(${QT_DEFINITIONS})
>
> ADD_DEFINITIONS(-DQT_PLUGIN)
>
> ADD_DEFINITIONS(-DQT_NO_DEBUG)
>
> ADD_DEFINITIONS(-DQT_SHARED)
>
> and it seems that QT_NO_DEBUG forces the plugin to be built
> in release mode. I've removed this and rebuilt and the plugin
> loads and runs correctly in Win32.
>
> However, I can't find much info on what QT_NO_DEBUG does -
> can anyone explain how this forces a release mode build.
> I'm not sure what the mechanism is.
>
>
QT_NO_DEBUG is a way of telling Qt which libraries (debug/release)
you're going to link with.
It influences the code generated for your plugins when it does
compatibility checks at load time.
What you did above would only work for release builds, not debug.
You can grab FindQt4.cmake/UseQt4.cmake from CVS if you want. This
should be fixed in 2.6 and maybe 2.4.8, so you don't have to do those
add_definitions.
Clint
--
[ signature omitted ]
Message 6 in thread
Stephen Collyer wrote:
> 5. The QPluginLoader::errorString() method returns "unknown error"
> in Win32.
In fact, I had the call to errorString() in the wrong place. It's
complaining that the plugin uses an incompatible Qt library so
it looks like I've managed to link it against the release libraries
somehow.
> 6. The plugin has been built with the same compile options
> as the executable that tries to load it.
Or so I thought. I need to figure out why this is not the case.
--
[ signature omitted ]
