Re: i686-pc-cygwin32 build of 19980628

[N8TM at aol dot com]

In a message dated 7/2/98 7:04:53 PM Pacific Daylight Time, d.love@dl.ac.uk
writes:

> conflicting prototypes for
>  __eprintf.  Its third arg is unsigned int in stdlib.h, but just int in
>  libgcc2.c.
I get some warnings along this line (I didn't note exactly where) but no
fatals.  I do find that the build fails to find include files at some point
unless both of the primary cygwin32 include directories are linked into
/usr/include or /usr/local/include, and even that hasn't enabled me to build a
working gmake under win95.  Cygnus make doesn't have trouble building
gcc-2.8.1 under win95, but neither make finds its way there with egcs. Yes,
the cygnus environment does set MAKE_MODE-unix. It's possible that having
installed gcc-2.8.1 and binutils first helped with include files under NT,
but, after doing that, I can use either 2.8.1 or egcs-1.0.2 to bootstrap egcs.
I don't recall being able to install binutils without first building
gcc-2.8.1, and I definitely wasn't able to build a working gmake on the
egcs-1.0.2 binaries.  Nor can I figure out why it was easier to build
gcc-2.8.1 under win95 but not gmake or egcs.  There's a lot more trial and
error than science in my experience.  I certainly came to appreciate that 64MB
is barely enough under NT.  I couldn't even check e-mail during builds, and
those took so long I thought I was back on the Mac.

I even tried e-mailing the gmake I built at the office back to my win95/Linux
box, and it didn't work any better than the one I tried to compile here.

Sunsite Imperial College came to my rescue again today when I needed fsplit on
NT at the office.  It's probably buried in those 14MB bsd-sources .tgz files
on the US sites, but I appreciated having it available by itself.
egcs/cygwin32, along with the Law/Wilson hp bug fixes, certainly look a help
in bridging the gap in the inevitable porting of old IBM360 style codes via
Unix to NT.