Re: i686-pc-cygwin32 build of 19980628

Re: i686-pc-cygwin32 build of 19980628

[Mike Stump]

> To: egcs@cygnus.com
> From: Dave Love <d.love@dl.ac.uk>
> Date: 02 Jul 1998 18:03:02 +0100

> I just tried something similar -- tasteless, I know -- using C and
> Fortran from that snapshot with a B19.1 base plus Khan's egcs-1.0.2
> and binutils.  I had a bit less success so far for some reason.

> I configured --prefix, --exec-prefix and --target to match cygwin,

Ouch, don't do that!

> having to set CC for configure to `gcc'.  It looks as though configure
> should be happy with gcc in the absence of cc, but it isn't; I haven't
> been inspired to investigate.

> It fell over building libgcc2 because of conflicting prototypes for
> __eprintf.  Its third arg is unsigned int in stdlib.h, but just int in
> libgcc2.c.  Am I missing some cygwin patch for this, perhaps?

Configure with a totally new prefix setting.  Also, the target is
i386-pc-mingw32.  This will generate a cross compiler, but it will
work.  You'll want to use --with-headers and --with-libs...  Just
point them to the mingw directories.

Re: i686-pc-cygwin32 build of 19980628

[Dave Love]

>>>>> "Mike" == Mike Stump <mrs@wrs.com> writes:

 >> I configured --prefix, --exec-prefix and --target to match cygwin,

 Mike> Ouch, don't do that!

OK, why not?  It's what I want and essentially works.

 Mike> Configure with a totally new prefix setting.  Also, the target
 Mike> is i386-pc-mingw32.  This will generate a cross compiler, but
 Mike> it will work.  You'll want to use --with-headers and
 Mike> --with-libs...  Just point them to the mingw directories.

I don't have mingw32.  Why do I want it?  What's wrong with cygwin?
(Bits of the Fortran runtime aren't available to a mingw32 target.)

Re: i686-pc-cygwin32 build of 19980628

[Mumit Khan]

On 3 Jul 1998, Dave Love wrote:

> I don't have mingw32.  Why do I want it?  What's wrong with cygwin?
> (Bits of the Fortran runtime aren't available to a mingw32 target.)

There's nothing wrong with cygwin other than rather lousy performance.

You're right however about the various bits that are missing from the
C RTL; given enough time, someone is bound to fill those in with Win32 
API. Nope, I'm not volunteering ;-)

Regards,
Mumit

Re: i686-pc-cygwin32 build of 19980628

[Mike Stump]

> To: egcs@cygnus.com
> From: Dave Love <d.love@dl.ac.uk>
> Date: 03 Jul 1998 10:22:33 +0100

> OK, why not?  It's what I want and essentially works.

Well, if it's what you want...  I am used to installing in new
directories, and not blowing away older compilers, but rather saving
them for reference.

> I don't have mingw32.  Why do I want it?  What's wrong with cygwin?
> (Bits of the Fortran runtime aren't available to a mingw32 target.)

I was confused.  I had mingw32 on the brain.  Nevermind.

Re: i686-pc-cygwin32 build of 19980628

[N8TM]

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.

Re: i686-pc-cygwin32 build of 19980628

[Dave Love]

>>>>> "Tim" == Tim Prince <N8TM@aol.com> writes:

 Tim> I do find that the build fails to find include files at some
 Tim> point unless both of the primary cygwin32 include directories
 Tim> are linked into /usr/include or /usr/local/include, and even
 Tim> that hasn't enabled me to build a working gmake under win95.

That wasn't necessary for me on DozeN'T with the appropriate
--prefix/--target args to configure.

 Tim> I don't recall being able to install binutils without first
 Tim> building gcc-2.8.1,

I built the current binutils with either the base cygwin compiler or
with egcs -- I don't remember which.

 Tim> Sunsite Imperial College came to my rescue again today 

McLoughlin is ghod!

BTW, I was unable to run dejagnu.  I can't remember the failure but
will have another go sometime unless someone knows a definite story on
it (980528) under cygwin.

Re: i686-pc-cygwin32 build of 19980628

[Mike Stump]

Cool, thanks.  I don't think there are many people doing this, so
having someone doing it and reporting status is good.  Any testing
results?  :-)

> From: tprince@cat.e-mail.com
> Date: Tue, 30 Jun 1998 14:53:02 EDT
> To: egcs@cygnus.com

> egcs-19980628 built successfully overnight on the following
> conglomeration:
> NT4
> Cygnus/B19.1 (with lots of added links)
> make-3.76.1 built with gcc-2.8.1
> binutils-2.9.1

i686-pc-cygwin32 build of 19980628

[tprince]

egcs-19980628 built successfully overnight on the following
conglomeration:
NT4
Cygnus/B19.1 (with lots of added links)
make-3.76.1 built with gcc-2.8.1
binutils-2.9.1

           To:                                              INTERNET - IBMMAIL

Re: i686-pc-cygwin32 build of 19980628

[Dave Love]

>>>>> "Tim" == Tim Prince <tprince@cat.e-mail.com> writes:

 Tim> egcs-19980628 built successfully overnight on the following
 Tim> conglomeration:
 Tim> NT4
 Tim> Cygnus/B19.1 (with lots of added links)
 Tim> make-3.76.1 built with gcc-2.8.1
 Tim> binutils-2.9.1

I just tried something similar -- tasteless, I know -- using C and
Fortran from that snapshot with a B19.1 base plus Khan's egcs-1.0.2
and binutils.  I had a bit less success so far for some reason.

I configured --prefix, --exec-prefix and --target to match cygwin,
having to set CC for configure to `gcc'.  It looks as though configure
should be happy with gcc in the absence of cc, but it isn't; I haven't
been inspired to investigate.

It fell over building libgcc2 because of conflicting prototypes for
__eprintf.  Its third arg is unsigned int in stdlib.h, but just int in
libgcc2.c.  Am I missing some cygwin patch for this, perhaps?

Re: i686-pc-cygwin32 build of 19980628

[Ian Lance Taylor]

   From: Dave Love <d.love@dl.ac.uk>
   Date: 02 Jul 1998 18:03:02 +0100

   It fell over building libgcc2 because of conflicting prototypes for
   __eprintf.  Its third arg is unsigned int in stdlib.h, but just int in
   libgcc2.c.  Am I missing some cygwin patch for this, perhaps?

Oddly, the prototype in stdlib.h was just copied from assert.h.  In
gcc/assert.h, __eprintf is declared to take a third argument of type
`unsigned', but in gcc/libgcc2.c, the third argument is of type `int'.
One of those should change to match the other.

I don't know why cygwin has an __eprintf prototype in stdlb.h.

Ian

Re: i686-pc-cygwin32 build of 19980628

[Mumit Khan]

On 2 Jul 1998, Dave Love wrote:

> It fell over building libgcc2 because of conflicting prototypes for
> __eprintf.  Its third arg is unsigned int in stdlib.h, but just int in
> libgcc2.c.  Am I missing some cygwin patch for this, perhaps?

Looks like I forgot to submit the tiny patch. Basically it's 'unsigned
int line' vs 'int line', right?

Mumit

Re: i686-pc-cygwin32 build of 19980628

[Dave Love]

>>>>> "Mumit" == Mumit Khan <khan@xraylith.wisc.edu> writes:

 Mumit> Looks like I forgot to submit the tiny patch. Basically it's
 Mumit> 'unsigned int line' vs 'int line', right?

Yes.  The only question is which changes.

BTW, having altered the libgcc2 version, the bootstrap does complete
OK.

Re: i686-pc-cygwin32 build of 19980628

[Bill Currie]

Dave Love wrote:
> I configured --prefix, --exec-prefix and --target to match cygwin,
> having to set CC for configure to `gcc'.  It looks as though configure
> should be happy with gcc in the absence of cc, but it isn't; I haven't
> been inspired to investigate.

I've had the same problem configuring packages for DJGPP.  The problem
is there is *NO* gcc on MS systems (it's gcc.exe) and configure looks
for gcc.  I *DON'T* know about cygwin, or the NT cli, but command.com
will not execute a program unless it is *.exe, *.com or *.bat.

Bill
-- 
Leave others their otherness

Re: i686-pc-cygwin32 build of 19980628

[Dave Love]

>>>>> "Bill" == Bill Currie <bcurrie@tssc.co.nz> writes:

 Bill> I *DON'T* know about cygwin, or the NT cli, but command.com
 Bill> will not execute a program unless it is *.exe, *.com or *.bat.

Actually, it's OK under cygwin's bash in general.  The problem was an
installation under the directory `/Program Files' and there's
presumably a problem somewhere with the space in the filename not
getting quoted.  I suppose I should debug it...