Patches for gnupg 1.0.7 / cygwin 1.3.10

Volker Quetschke quetschke at
Wed Jun 5 16:26:02 CEST 2002

Hi Werner,

 > > cases with __CYGWIN__ for the file handling to use its own (standard
 > > posix) file handling. Cygwin does have a /dev/random, therefore I
 > > changed from rndw32 to rndlinux.
 > This seems to be a new feature - did you review the architecture of
 > this device?
I got the hint from the cygwin list and I tried to use it with the build 
of gnupg. There were two include files missing for rndunix but it 
compiled with rndlinux. And a cygwin build gpg works with rndlinux.

I don't know how good the generated entropy is. This question goes to 
the cygwin list. How generated? How good?

 > > Please review the patch and implement if possible. It mainly removes
 > > special cases for cygwin.
 > There are two main reason why Cygwin is not supported and why the
 > existing support may be dropped in the future:
 > 1. There are conflicts between passed file descriptors.  Cygwin and
 >    Windows use different semantics for that and GnuPG has already a
 >    mapping between the external file descriptors and those used with
 >    the CRT.  Now knowing what version of GnuPG is running on a Windows
 >    box is a bad thing for other applications.  Adding extra code to
 >    check for this is too complicated and thus error prone.
 > 2. Having a native Windows binary is a clear advantage for maintenance
 >    and support.
 > What we will support is cross compiling using a gcc running under
 > Cygwin to a native windows application.

Ok, but first things first, at the moment gnupg 1.0.7 / current cvs 
version don't build OOB. Ok, if you start the make several times it 
finishes after all. This was due to the fact that the in:
case "${target}" in
         # special stuff for Windoze NT
[few lines deleted]
                   [because the Unix gettext has too much overhead on
                    MingW32 systems and these systems lack Posix functions,
                    we use a simplified version of gettext])
set try_gettext="no". Therefore AM_GNU_GETTEXT doesn't get called, and 
so $(RANLIB) isn't set. Solution: Cygwin can use the full gettext, so 
remove the *-*-cygwin* from this case and create the same case for 
*-*-cygwin* without AC_DEFINE(USE_SIMPLE_GETTEXT,1 and try_gettext="no".

That is all to make the cygwin target compile OOB without changing 
anything to the gpg file handling. Full windows path compatible, as you 
 > What we will support is cross compiling using a gcc running under
 > Cygwin to a native windows application.

It would also be nice if you incorporate the fix for the dynamic module 
handling, it is a known feature that automake can't always guess right 
if there is a .exe missing:
 > +			# The $(EXEEXT) is needed to help automake

I can send you a patch for this if you don't like the rest.

Now I would like to come back to your second point.
 > 2. Having a native Windows binary is a clear advantage for maintenance
 >    and support.

Yes, but you don't build native windows binaries just with the cygwin 
build. If you build something under cygwin this uses the cygwin1.dll, 
this is not a good solution for native windows tools.

You can use the following build instructions to build gpg as a native 
windows application. (without cygwin1.dll)

export CC="gcc -mno-cygwin"
export RANLIB="ranlib"

./configure --host=i686-pc-mingw32 --target=i686-pc-mingw32
echo "all:" > po/Makefile

( The po/Makefile is not generated without AM_GNU_GETTEXT set, therefor 
you have to generate your own.
And you need to change the
#ifdef __CYGWIN32__
# include <winioctl.h>

to just

#include <winioctl.h>
(I don't now if you need winioctl.h for a pure mingwin build)

because this is needed. This leads me to the main point: __CYGWIN__ is 
not defined at the moment, we are: __MINGW32__.
Even using a cygwin environement to create a native windows executable 
doesn't need any __CYGWIN__ preprocessor directives.

If you use just cygwin, then you want to have a POSIX environement, like 
my mutt, or Xfree86, or even KDE 2.2.2 .
All these programs don't like windows pathes.

If you do not want to support cygwin you can start to remove every 

Why not start with my previously posted patch? ;-) OK, maybe I should 
have a look at the rndlinux code, but it works at least.

I think it is very convenient to have a native cygwin gpg and it doesn't 
  interfere with a native windows build.

Bis bald


More information about the Gnupg-devel mailing list