RESOLVED: GCC 2.95.2 make problems under Cygwin 1.1.4

[Tim Prince]

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