Documentation on W32

[LRN]

-----BEGIN PGP SIGNED MESSAGE-----
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 mingw.org 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 mingw.org 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 mingw.org 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 mingw.org will be able to compile gnutls later
on. This patch fixes the issue for me today, and that's all i need.

The __MINGW32_MAJOR_VERSION <= 3 && __MINGW32_MINOR_VERSION <= 20
check is there in case mingw.org fixes this after all (in that case
increase the numbers to the release that adds CertEnumCRLsInStore() to
the import library).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQVEZAAAoJEOs4Jb6SI2Cwwd0H/AmFzFbjXiHmyWIbJUtQGULp
QtKg2zPZdwf1rOj7NUH7N2oLqwMLcPsKTzsEAZZ19R1KWtE8P7hH5x4mIeMH/tbe
T7qQ4UzVcnBk8KgMA61W1d0M3GQr2sKCuhG+wsD3PGEWmVweu7cLgOTK39QcqVqr
dAnxQzoZ2kUeHCv0xnQc4Wf6IH8MK+RnQApLe6QmtQ8uGn16yUhNICQRwGyfKdDd
0OiWdyZ5YxbSO68jSsTgk1/KKP43jCCVihBR7813m7w4IhT+5yvyh+oY9EyMh3xF
YJbx8pOLOoDRXQeWWkam1XX7emNWrfZFY2zYd1bBgsDcKxJEdcsLmgxEz3eB0HY=
=/z1J
-----END PGP SIGNATURE-----