Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <000b01c01581$c8c60900$92d698d1@hotrod>
From: shell AT shellware DOT com (Shell M. Shrader)
To: <cygwin AT sources DOT redhat DOT com>
References: <001601c01574$d6afd0d0$92d698d1 AT hotrod> <057601c0157c$15a2e960$4f6c8ad1 AT intel9txl52pzr>
Subject: Re: RESOLVED: GCC 2.95.2 make problems under Cygwin 1.1.4
Date: Sun, 3 Sep 2000 04:34:32 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

Has anyone published a list of the GCC 2.95.2 prequisites for Cygwin 1.1.4?
It would've made this process much easier had I been able to locate a single
point to reference the archives and patches from.

Regardless, I'm happy.... I got my build.  Now I'm off to tackle libgcj.
I've been reading about cvs.  Would it have made this less painful?

Shell

----- Original Message -----
From: "Tim Prince" <tprince AT computer DOT org>
To: "Shell M. Shrader" <shell AT shellware DOT com>; <cygwin AT sources DOT redhat DOT com>
Sent: Sunday, September 03, 2000 3:53 AM
Subject: Re: RESOLVED: GCC 2.95.2 make problems under Cygwin 1.1.4


> This bug stemmed from a change in the Windows headers.  Mumit Khan arrived
> at a fix for this which worked on all the varieties of Windows over a year
> ago and it has been in the 2.96 snapshots, as well as the cygwin patches
to
> 2.95, ever since.  Various versions of treating LARGE_INTEGER as a long
long
> are successful.  Another possible variation is to use the W9x version
> (QueryPerformance calls) under NT and 2K. That is about the only practical
> solution on those installations where the resolution of the NT timer is
not
> as good as the usual 0.01 second.  No way is known to detect such
> installations other than to test the timer resolution at run time.  The
> stuff which is in the snapshots already stretches usual gcc policy by a
wide
> margin.  But, many of us want to make .exe files which will run on either
> W9x or NT/2K.  Even if the C people don't care whether clock() is broken
on
> 9x.
> ----- Original Message -----
> From: "Shell M. Shrader" <shell AT shellware DOT com>
> To: <cygwin AT sources DOT redhat DOT com>
> Sent: Sunday, September 03, 2000 12:01 AM
> Subject: RESOLVED: GCC 2.95.2 make problems under Cygwin 1.1.4
>
>
> I was able to finally get GCC 2.95.2 make(ed) and installed under the
Cygwin
> Net release on my Win2k machine but it wasn't without dificulties.
>
> I had to modify two routines to get the make to succeed:  etime_.c and
> dtime_.c
>
> etime_.c & dtime_.c both reference the HighPart and LowPart properties of
> the LONG_INTEGER datatype.  However, they nor any of their included
modules
> #include winnt.h which is the only win32 header I could locate that
defines
> this structure.
>
> In both routines the HighPart and LowPart properties were being used to
> facilitate a hack for non NT win32 systems---
> ...
>          LARGE_INTEGER freq;
> ...
>  /* We need to use this hack on non-NT platforms, where the first call
>     returns 0.0 and subsequent ones return the correct value. */
>  if (win32_platform != VER_PLATFORM_WIN32_NT)
>    {
> ...
>              clock_freq = ((unsigned long long) freq.HighPart << 32)
>                           + ((unsigned) freq.LowPart);
> ...
>      count = ((unsigned long long) counter_val.HighPart << 32)
>              + (unsigned) counter_val.LowPart;
> ...
>
> I opted to comment out the references to HighPart and LowPart and simply
> return a value of 1 in both routines because I'm on an NT system and could
> care less of the impact to non-NT systems as this is a localized
> installation.  I suspect the proper thing to do would be to #include
winnt.h
> or track down the source of LARGE_INTEGER without including winnt.h but I
> was fearful that I would cause additional conflicts and I'm tired of
messin'
> with the make.
>
> Previously I had tried to use the GCC Cygwin patches to take care of the
> compiler warnings but gave up as they introduced incoherent FATALs within
my
> Stage 1 build.  Guess I'll soon find out the impact of the multple
compiler
> warnings I got.
>
> Am I the only W2K gcc-2.95.2 / Cygwin 1.1.4 user out there to have this
> problem?  I find it very hard to believe that I'm the first W2K gcc-2.95.2
/
> Cygwin 1.1.4 user.
>
> Shell
>
>
>


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com