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: <002301c015e3$280c0610$218d88ac@timayum4srqln4>
From: "Tim Prince" <tprince AT computer DOT org>
To: "Shell M. Shrader" <shell AT shellware DOT com>, <cygwin AT sources DOT redhat DOT com>
References: <001601c01574$d6afd0d0$92d698d1 AT hotrod> <057601c0157c$15a2e960$4f6c8ad1 AT intel9txl52pzr> <000b01c01581$c8c60900$92d698d1 AT hotrod>
Subject: Re: RESOLVED: GCC 2.95.2 make problems under Cygwin 1.1.4
Date: Sun, 3 Sep 2000 13:11:12 -0700
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.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

You need to find one of the cygwin mirror sites which has the source
tarballs alongside the binaries which setup downloads.  gcc-2.95.2 is one of
those which is significantly different from the standard gnu version.
binutils likewise.  Apparently, if you modify binutils/bfd, you must rebuild
the gcc as well, or g++ libraries will break.
----- Original Message -----
From: "Shell M. Shrader" <shell AT shellware DOT com>
To: <cygwin AT sources DOT redhat DOT com>
Sent: Sunday, September 03, 2000 1:34 AM
Subject: Re: RESOLVED: GCC 2.95.2 make problems under Cygwin 1.1.4


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


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