RESOLVED: GCC 2.95.2 make problems under Cygwin 1.1.4

[Shell M. Shrader]

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@computer.org>
To: "Shell M. Shrader" <shell@shellware.com>; <cygwin@sources.redhat.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@shellware.com>
> To: <cygwin@sources.redhat.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@sourceware.cygnus.com