Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <3CFE118D.2010900@scytek.de>
Date: Wed, 05 Jun 2002 15:26:37 +0200
From: Volker Quetschke <quetschke AT scytek DOT de>
User-Agent: Mozilla/5.0 (Windows; U; Win98; de-DE; rv:0.9.4) Gecko/20011019 Netscape6/6.2
MIME-Version: 1.0
To: gnupg-devel AT gnupg DOT org
CC: cygwin AT cygwin DOT com
Subject: Re: Patches for gnupg 1.0.7 / cygwin 1.3.10
References: <3CFCE281 DOT 3030806 AT scytek DOT de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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 Configure.ac in:
---
try_gettext=yes
case "${target}" in
     *-*-mingw32*|*-*-cygwin*)
         # special stuff for Windoze NT
         ac_cv_have_dev_random=no
[few lines deleted]
         AC_DEFINE(USE_SIMPLE_GETTEXT,1,
                   [because the Unix gettext has too much overhead on
                    MingW32 systems and these systems lack Posix functions,
                    we use a simplified version of gettext])
         try_gettext="no"
         ;;
---
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 
said:
 > 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:
 > -         DYNAMIC_CIPHER_MODS="$DYNAMIC_CIPHER_MODS $name"
 > +         DYNAMIC_CIPHER_MODS="$DYNAMIC_CIPHER_MODS $name\$(EXEEXT)"
 > +			# 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"

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

( 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>
#endif

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 
__CYGWIN__.

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

      Volker


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/