The following reply was made to PR toolchain/36159; it has been noted by GNATS.

From: "Valeriy E. Ushakov" <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc: toolchain-manager@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, bsh@netbsd.org
Subject: Re: toolchain/36159: Cross build on Cygwin fails (sha1.c)
Date: Tue, 17 Apr 2007 17:23:28 +0400

 On Tue, Apr 17, 2007 at 11:55:01 +0000, Matthias Scheler wrote:
 
 >  On Tue, Apr 17, 2007 at 04:05:00AM +0000, bsh@NetBSD.org wrote:
 >  > Index: sha1/sha1.c
 >  > ===================================================================
 >  > RCS file: /u0/cvsupbase/cvsroot-netbsd/src/common/lib/libc/hash/sha1/sha1.c,v
 >  > retrieving revision 1.2
 >  > diff -u -r1.2 sha1.c
 >  > --- sha1/sha1.c	27 Oct 2006 21:25:21 -0000	1.2
 >  > +++ sha1/sha1.c	17 Apr 2007 01:42:46 -0000
 >  > @@ -146,10 +146,10 @@
 >  >   * Hash a single 512-bit block. This is the core of the algorithm.
 >  >   */
 >  >  void SHA1Transform(state, buffer)
 >  > -    u_int32_t state[5];
 >  > +    uint32_t state[5];
 >  >      const u_char buffer[64];
 >  >  {
 >  > -    u_int32_t a, b, c, d, e;
 >  > +    uint32_t a, b, c, d, e;
 >  >      CHAR64LONG16 *block;
 >  >  
 >  >  #ifdef SHA1HANDSOFF
 >  
 >  This is not the correct fix. "src/tools/compat/configure" checks for
 >  the existence of "u_int32_t". Can you please check "config.log" to
 >  find out what the result of that check was?
 
 My reading of the report is that the problem is not lack of u_int32_t,
 the problem is that u_int32_t and uint32_t get defined incompatibly.
 Anyway
 
 . it's better to use the same type in the declaration and definition
 . uint32_t is standard, so it's the preffered one
 
 So I think the fix is fine.
 
 
 SY, Uwe
 -- 
 uwe@stderr.spb.ru                       |       Zu Grunde kommen
 http://snark.ptc.spbu.ru/~uwe/          |       Ist zu Grunde gehen