Suggestions for gpgme on mingw-w64
wk at gnupg.org
Fri Sep 4 13:32:58 CEST 2015
On Fri, 4 Sep 2015 12:42, jeroen.ooms at stat.ucla.edu said:
> ## w32spawn
> home directory, and then dynamically loads them when needed. Therefore
> _gpgme_get_inst_dir() returns the installation directory of the main R
> software, which is not writable by the user.
You should really try to use the gpgme DLL and not link it statically -
this will return the installation directory of the DLL. However, I know
that this is sometimes not easy to achieve.
> It would be really nice if we could manually set the path to
> gpgme-w32spawn.exe, for example with a runtime environment variable or
> via gpgme_set_global_flag("gpgme-w32spawn", ...) or something similar.
Well, if that is really required it can be done. Dymnamically loaded
code has a lot of problems which we can fortunately solve on Windows by
using a DLL. If you don't see a chance to use a DLL, such an option can
> Alternatively gpgme could search the PATH as well.
No. That may turn up an incompatible versions of the helper and we get
trouble analyzing bug reports.
> One final suggestion is that the error message in
> _gpgme_get_w32spawn_path could be improved a bit. I spent a lot of
> ## finding gpgconf
> There are several methods described to find gpg, and none of them
> worked on my windows 64 system, though I have a completely standard
> gpg4win installation.
Thing will be better with GnuPG 2.1 - the installer uses a weel-known
installation directory and the latest gpgme knows about it and only
falls back to the standard gpgwin install directories if no 2.1 is
> Finally, the find_program_at_standard_place() function in w32-util.c
> checks CSIDL_PROGRAM_FILES (which corresponds to c:/program files/).
> However on a windows 64 machine, the default directory of gpg4win is
> actually in CSIDL_PROGRAM_FILESX86 (which corresponds to c:/program
> files (x86)/), so gpgme should check this dir as well. After I changed
Interesting. Does that mean that for a 64 bit process, the
CSIDL_PROGRAM_FILES is different for than for a 32 bit process? I guess
that makes sense.
Okay to check CSIDL_PROGRAM_FILESX86 after CSIDL_PROGRAM_FILES on a 64
bit Windows? For my understanding this would also prefer a 64 bit
version of GnuPG (which does not yet exist) over a 32 bit version.
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gnupg-devel