Documentation on W32

LRN lrn1986 at
Sat Sep 15 11:11:31 CEST 2012

Hash: SHA1

On 15.09.2012 13:01, Nikos Mavrogiannopoulos wrote:
> On 09/13/2012 08:39 AM, LRN wrote:
>> On 13.09.2012 1:21, Nikos Mavrogiannopoulos wrote:
>>> On 09/11/2012 09:11 PM, LRN wrote:
>>>> Right now building gnutls with documentation on W32 is 
>>>> practically impossible: * documentation requires files
>>>> generated by autogen, * non-ancient versions of autogen
>>>> require guile to work, * guile doesn't work on W32 * ancient
>>>> versions of autogen might now work for gnutls, and are very
>>>> difficult to build with modern autotools. Is autogen really
>>>> necessary? Can these files be pre-generated and shipped in
>>>> the tarball?
>>> The autogen files are pre-generated and shipped in the
>>> tarball. Maybe make considers them old and tries to rebuild
>>> them. Which files have this issue in your system?
>> OK, here's what i do: 1) I unpack gnutls-3.0.23.tar.xz 2) I patch
>> it (patches are attached; don't take patch 0004 seriously,
>> it's a workaround for braindead w32api library)
> I'm wondering what is Loaded_CertEnumCRLsInStore() that you use
> instead of CertEnumCRLsInStore()? If the mingw32 issue is
> widespread I could include that patch in gnutls.
MinGW Win32API package does not have CertEnumCRLsInStore() prototype
in its headers (easily fixable by declaring the prototype yourself)
AND it doesn't export CertEnumCRLsInStore() in its import library for
crypt32. THAT is the real problem. The only way to fix that is to
patch mingw w32api package and rebuild it. I can't tell users to
recompile one of the most basic packages in their system, obviously.
Submitting a patch to takes efforts, it will be in the queue
for some unknown amount of time, and then one will have to wait for
the next win32api release.
Very little fun in that.

So instead i load crypt32.dll manually and get CertEnumCRLsInStore()
from it via GetProcAddress(), and put that address into
Loaded_CertEnumCRLsInStore static global variable, so that it can be
called later.

I'm not insisting that this is the right way (though it certainly
looks well enough; should even be thread-safe, unless someone does
concurrent gnutls initialization), but since i'm planning to migrate
from to mingw-w64 in the future (mingw-w64 doesn't have
problems like this - its headers and crt are pretty much complete), i
don't really care how will be able to compile gnutls later
on. This patch fixes the issue for me today, and that's all i need.

check is there in case fixes this after all (in that case
increase the numbers to the release that adds CertEnumCRLsInStore() to
the import library).

Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla -


More information about the Gnutls-devel mailing list