W32 build fixes for gnupg-2.0.19

Fri Feb 1 04:11:54 CET 2013

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26.01.2013 23:37, Werner Koch wrote:
> On Sat, 26 Jan 2013 04:47, lrn1986 at gmail.com said:
>> Subj is attached.
> 
> Please explain the problems you are trying to fix.
The single problem is GnuPG not building with MinGW/MSys.
The separate issues that affect the building process were described
briefly in my previous message (for each separate patch).

> Note that we still need copyright assignments for GnuPG
I have copyright assignment for GnuTLS. Would that suffice? If not,
then that still isn't a problem - i need a copyright assignment for
binutils anyway, so i'm going to get a generic GNU one in foreseeable
future (depends mostly on how fast the postal service works).
Also, 1-2-line patches (2/3 of the files i've sent) do not merit a
copyright.

> and that building requires a full fledged POSIX host; i.e. building
> on a Windows host does not work.
Let's see.

0001-fix-regex-test-on.mingw32.all.patch:
Adds one #include <stddef.h> to a configure test.
I doubt that including gcc's own stddef.h will break anything.

0002-fix-stringhelp-on.mingw32.patch:
First half fixes an obvious bug in the code.
The original function looked like this:

const char *
gethome (void)
{
  if (!home_buffer)
    {
      char *home = getenv("HOME");

#if defined(HAVE_GETPWUID) && defined(HAVE_PWD_H)
      if(home)
        home_buffer = xstrdup (home);
      else
        {
          struct passwd *pwd;

          pwd = getpwuid (getuid());
          if (pwd)
            home_buffer = xstrdup (pwd->pw_dir);
        }
#endif
    }
  return home_buffer;
}

Which begs the question: why getenv("HOME"), if you don't
HAVE_GETPWUID or don't HAVE_PWD_H?
And then another question: if home envvar is defined (is not NULL),
then why not xstrdup it to use as gethome() result? It has no relation
to getpwuid or pwd.h.
This part fixes gethome() to actually work on W32 (when HOME is defined).
The second part of that patch is W32-only (see the #ifdefs), and thus
does not affect other platforms. It tries to use USERPROFILE envvar as
a substitute for HOME, if HOME is not defined.
If you don't like the second part (for whatever reason), omit it, it's
optional anyway.

0003-fix-tmpfile-on.mingw32.patch:
This is probably what you meant when asked for copyright assignment
and for cross-compilation testing.
First, it's W32-only (see the #ifdefs), so it will not affect other
platforms.
Second, because it loads functions at runtime, it will cross-_compile_
successfully. Running successfully is another matter. It did run on my
NT 6.1.7601 though.
Also see below for how this patch can be improved if you bump the
minimal W32 version to 0x501.

> If you need that I suggest to run a decent Debian version in a VM.
I have a Debian laptop, and also have Debian on my server.
I'm totally willing to test these under Debian, if you point me to
some cross-compilation-of-GnuPG-from-Debian-to-W32 docs.

> 
>> minimal target W32 platform is W2000 (0x500), which means that
> 
> I can't guarantee that GnuPG-2 will run on W2000. I have no test 
> system anymore and in any case W2000 reached EOL a long time ago.
My assumption about minimal target is based upon this code:
#ifdef HAVE_W32_SYSTEM
# define WINVER 0x0500  /* Required for AllowSetForegroundWindow.  */
# include <windows.h>
#endif
in sysutils.c

I do not know who added it there, and when, but it means that GnuPG
(compiled as-is, if you manage to do that) will not run on anything
older than W2000 (W32 runtime linker will abort, claiming that it
can't find AllowSetForegroundWindow in User32.dll).

If you are willing to bump the minimal version to XP (0x501) at least,
that will GREATLY simplify the last patch, as it will not need to load
functions at runtime - it will just use CryptoAPI directly. By the
way, all that is explained in the comments in the patch itself. But
you probably don't have enough free time to read comments.

Anyway, give the minimal version bump a thought. Please.

> 
>> check' passes all tests successfully (i did test all 3 versions 
>> of the random generator).
> 
> Those tests don't test the quality of the RNG!  To make sure that 
> it works as expected you need to do quite some research.
This random number generator is used ONLY to generate names for
temporary files (mktemp()).

The original code in gnupg_mktemp did not use RNG at all, it used a
combination of process ID and system CPU time (tick count), and did
some obscure magic with these numbers. And with it sysutils tests
failed for me. With my patches they don't fail, they pass. Which was
my goal.

By the way, i have two more patches (or, more likely, pointers; they
are not fit for merging as-is) for you. Do you even want them?

P.S. Just realized that my original reply was not sent to the ML.
Here's the same message again.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRCzJ3AAoJEOs4Jb6SI2Cwu4cH/ijxVZlXqz2+MJDAr7z6YX5F
RWJjVOv9QxZyahBB2av4SLenVpvwWhIIVUBNGd0AlFbJ95YzI9RPHQFUDLZqt4wf
7E89AGZQV4HcDHxBMCbSKWmqmExBy5S1mg/5G2T57hi6D4SVTT98eb/Pw/LbwN1u
eHQ9mrFsuRqut5wy2ssBaPkLZB0MB4r3JLr4WaOTXPIzipFBRxTfiJJzIjHLhx6T
BQNETwKwgfZ2XQQD0hUlbgkvcjb4DMi96VkcUgfvJPXdtaqEPLUpv7qiEAxDjycX
flDZMmAf8KKN9B2t9cs2yZhqGTZKQ6JSL6CNe8XIBQgTc8F9JGr9G46Umj47vP4=
=fDJd
-----END PGP SIGNATURE-----