Simon,
Did you ever get help with this?
I’m not an expert on gpg4win, but I’ve just upgraded to 2.1.0rc2, and noticed a similar error. I might have had a related problem when I previously installed 2.0.4, but I cannot remember the details anymore.
I think my installation is proper now, so here is what I had to do:
I needed to add the path to the GnuPG and GnuPG\pub folders to my PATH system variable. I think with 2.0.4, only adding the path to GnuPG\pub was necessary, but as I say I cannot recall anymore.
If you’re not familiar, to modify the system variables, you need to go to your System control panel. In Vista: Start Menu → right-click Computer → select Properties. Then, choose Advanced system settings. Then, click the Environment Variables button.
There are separate sections for user-specific and system-wide versions of the variables. If you’re the only one using gpg4win, you could go with editing the user variable PATH. Otherwise, I would choose the system variable PATH.
So, select the PATH variable and click Edit. Move the insertion point to the end of the line of variable value text, add a semicolon (
and type in the full path to GnuPG, as installed by gpg4win. Then, repeat for GnuPG\pub. For example, on my system:
(existing path variable value text);C:\Program Files\GNU\GnuPG;C:\Program Files\GNU\GnuPG\pub
“OK” your way out of the dialog boxes.
This seemed to work for me.
Specifically, after installing 2.1.0rc2, and trying to run Kleopatra for the first time, I got error messages stating things to the effect of: kbuildsycoca4.exe - libkdecore.dll could not be found, and similar.
I verified that the “missing” files were actually present in the GnuPG folder, so the problem was that the context was wrong when kleopatra.exe and kbuildsycoca4.exe were started, and they could not find their libraries.
I vaguely recall last year, a Windows security vulnerability that relied upon the then default behavior of all versions of Windows to use the current working directory as part of the library search path. Malware was using this as a way to bootstrap itself into otherwise tightly secured systems. Microsoft responded by publishing new rules for developers to follow regarding library search path procedures, and issued a patch which modified the behavior and a registry entry which allowed technical users to fine-tune it.
As a consequence, software which depended on the previous default library search path behaviors could suffer problems if, suddenly, they could no longer find needed library files.
I’m not an expert, but it feels like something like this might be at play in either the current GnuPG-supporting GNU software ecosystem for Windows, and/or the current way it’s integrated and packaged by Gpg4win.
Have encountered the problem I detailed above on both Windows XP and Windows Vista systems. Modifying the PATH variable straightened things out on each system.
To your specific problem as you report it, it is definitely a library-related problem. And doing as I did might or might not solve it. You could be having a problem with more than one set of QtCore libraries on your system (perhaps coming in with other open-source software designed to use Qt libraries) and the Gpg4win tools are finding one of those other libraries which is of a slightly different version than the one the Gpg4win tools were build against.
My 99 cents.
Can anyone else similar experiences with the 2.1.0rc2 software?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
iEYEAREDAAYFAk1sRZsACgkQRTNjCmtFEDWkfwCfdd4nTcgzWK8HgaaCYn43daJ/
IK8AoIqbe9r4GSChbwvzhQui0xCXB+FR
=hzIK
-----END PGP SIGNATURE-----