debugging QT plugins, was: debugging ofx file import

Jack ostroffjh at users.sourceforge.net
Sun Jan 20 00:16:06 GMT 2019


On 2019.01.14 14:37, Ralf Habacker wrote:
> Am 14.01.19 um 20:31 schrieb Jack: 
> >> The patch from https://phabricator.kde.org/D16764 should help.
>> Thanks Ralph, and I'll give it a try, but I had thought an IDE  
>> (QT-Creator in this case) would know where things are, since it  
>> insists on compiling the whole project before starting to debug it.
> This is true for shared libraries, but kcoreaddons does not know from  
> which directory to load the plugins, which is provided by the patch.  
> And kmymoney5 could not load anything without plugins.
Once I solve the basic problem of getting QT to load the newly compiled  
plugins instead of the system installed ones, I'll go back to whether  
this can be done in QT-Creator by creating an appropriate build/run  
configuration, but for now, I can't even get the basics right.
> 
> Ralf
I admit I have not actually applied the patch, but it seems the real  
critical parts are the new instructions in Quick-start 5 to run from  
the build directory.  I'm running on Linux, and I can see that things  
get compiled and installed as expected.

I've been trying all sorts of variations, but going back to the most  
straightforward:

My build directory is parallel to the source, not under it.  This  
should be fine, shouldn't it?

I'm using ninja instead of make, so one line syntax is different.

cd build
DESTDIR=./tmp ninja install  (This does install under build/tmp - where  
the original prefix is /usr/local, my choice for a self-compile instead  
of /usr)

In addition to setting the environment variables listed, I also set  
QT_DEBUG_PLUGINS=1 to get more information at runtime.

I think there is some inconsistency in the variables settings -  
XDG_DATA_DIR uses ./tmp/usr/local/share, but QT_PLUGIN_PATH uses ./lib  
where I think it should be ./usr/local/lib64/plugins (. should be same  
as $PWD, lib vs lib64 depends on the local setup, but that variable  
needs the /plugins on the end) and LD_LIBRARY_PATH should also be  
./usr/local/lib64 not just ./lib.  Finally the executable should be  
./usr/local/bin/kmymoney (It's OK for the readme to use /usr and not  
/usr/local, that's only my personal preference, but if so, should  
XDG_DATA_DIR include the "local"?)

So - If I grep through the output cause by setting QT_DEBUG_PLUGINS,  
and look for "Found metadata" or "loaded library" also mentioning  
ofximporter.so, I get

Found metadata in lib  
/home/jack/KDE/KMM/build50debug/tmp/usr/local/lib64/plugins/kmymoney/ofximporter.so,  
metadata=
Found metadata in lib /usr/lib64/qt5/plugins/kmymoney/ofximporter.so,  
metadata=
Found metadata in lib /usr/lib64/qt5/plugins/kmymoney/ofximporter.so,  
metadata=
loaded library "/usr/lib64/qt5/plugins/kmymoney/ofximporter.so"
Plugins: ofximporter loaded
Found metadata in lib  
/home/jack/KDE/KMM/build50debug/tmp/usr/local/lib64/plugins/kmymoney/ofximporter.so,  
metadata=
Found metadata in lib  
/home/jack/KDE/KMM/build50debug/tmp/usr/local/lib64/plugins/kmymoney/ofximporter.so,  
metadata=
Found metadata in lib  
/home/jack/KDE/KMM/build50debug/tmp/usr/local/lib64/plugins/kmymoney/ofximporter.so,  
metadata=

So it finds the new plugin four times while looking for metadata, but  
finds the system version twice, and still manages to load the system  
version instead of the new version.

Can anyone tell what I'm doing wrong?

I might yet uninstall my system version, to see if it does load the new  
plugins.  If so, then it's an issue with search order for all the  
plugin dirs it uses.  If it still won't load the new plugins, then I'm  
really stumped.

Any other thoughts or suggestions?

Jack


More information about the KMyMoney-devel mailing list