building egcs-1.1.2-pre1 on cygwin-b20.1

building egcs-1.1.2-pre1 on cygwin-b20.1

[tprince]

As the cygwin target is still officially unsupported, I'm not sending
this to egcs-bugs.  Still, I must say the work which has gone into
making egcs workable on Windoze is much appreciated.

1.  Mumit Khan's egcs-1.1.1 patches work cleanly on a fresh
expansion of the 1.1.2-pre1 tarball, and are needed to avoid the
"multiple definition" errors when linking with libstdc++, and to
make libf2c work on W95.  The most recent development
snapshot seems to have cured the "multiple definition" problem
without needing such patches.  I haven't checked whether there
are other reasons remaining why they're needed.  I've been
testing the lib2c stuff with my correction to Mumit's correction.

2.  Mumit's advice to configure --host=i586-cygwin32 is
important, particularly if using pre-cygwin-b20.2 snapshots.  On
W95, it's necessary to symlink the target directories to the
i586-pc-cygwin32 default counterparts; this takes care of the
tendency of configure to ignore the specifications and take the
default at times.  Also necessary, at least on W95, are symlinks
to make appropriate files appear in /usr/include and /usr/lib.

3. make bootstrap-lean runs well on NT4/SP3, if properly
configured.  On W95, I have not been able to complete a
bootstrap, but a plain make runs well.  Current development
snapshots do OK with bootstrap on W95; they stop right before
compare-lean, but the rest may be complete successfully with
intervention.

4.  configure on W95 fails to recognize texinfo as an unsupported
directory.  This is the first time I've ever had this problem.  The
associated problem of having to do 'make -k install' because
install does not accept an unbuilt texinfo or chill is still with us,
regardless of which decision configure has made.

5.  'make -k install' doesn't run automatically into the library
installations.  On W95, it's necessary to go into each of these
directories and run install there.   On NT, it may be necessary to
start by running configure individually in each of these
directories.  Failure to do this will give you broken g++ and g77
libraries.  This seems to be caused by the inability of Windoze to
deal with aborted recursive makes.  This happens both with
cygwin-b20.1 and pre-b20.2.  egcs Makefile seems to be full of
these recursive makes which are expected to abort.

6.  On NT4, there are many redundant re-makes.  This may be
caused by the randomness of the 2 low-order bits of Windoze file
time-stamps.  It reminds me of being on jury duty, trying to guess
whether cygwin should mask out the random bits in an attempt
to present a monotonic time-stamp, or whether configure should
accept a certain level of tolerance.  W95 has the same
non-monotonicity, but it doesn't prolong the configure and build.

7. testsuite runs up to a point.  libstdc++, gcc, g++, and g77
compile-only tests work under cygwin-b20.1 on NT and b20.2 on
W95.  Execute tests don't work on NT, but do on W95/b20.2, until
an un-recoverable crash occurs.

8.  x86 performance with -Os -malign-double
-march=pentiumpro is quite satisfactory, especially on
i686-pc-linux-gnulibc1.  It's generally in between the
performance of lf90 and lf95, and better than the NAG f95 beta
(unless you plug in egcs as a back end).  On hppa and irix, the
development snapshots give faster running code, but currently
have disabling g77 bugs.  Also, the development snapshots are
more likely to give good performance with -O2 on x86.
Dr. Timothy C. Prince
Consulting Engineer
Solar Turbines, a Caterpillar Company
alternate e-mail: tprince@computer.org

           To:                                              INTERNET - IBMMAIL

Re: building egcs-1.1.2-pre1 on cygwin-b20.1

[Mumit Khan]

On Fri, 19 Feb 1999 tprince@cat.e-mail.com wrote:

> As the cygwin target is still officially unsupported, I'm not sending
> this to egcs-bugs.  Still, I must say the work which has gone into
> making egcs workable on Windoze is much appreciated.
> 
> 1.  Mumit Khan's egcs-1.1.1 patches work cleanly on a fresh
> expansion of the 1.1.2-pre1 tarball, and are needed to avoid the
> "multiple definition" errors when linking with libstdc++, and to
> make libf2c work on W95.  The most recent development
> snapshot seems to have cured the "multiple definition" problem
> without needing such patches.  I haven't checked whether there
> are other reasons remaining why they're needed.  I've been
> testing the lib2c stuff with my correction to Mumit's correction.

I ran the testsuite a few days ago after pre1 into my local tree, and
so far no regressions. In fact, all the C++ testsuite false negatives
are gone.

The multiple definition problems are still there, just harder to tickle.
Jason has added quite a few linkage patches to the dev tree, so 1.2 
should be better in this respect.

I've added your libf2c correction as well and will be in my binary 
release right after 1.1.2 comes out.

As for the bootstrap errors, I'll try it out on an NT and Win9x and 
see if I can duplicate your problem.

Thanks very much for the detailed feedback.

Regards,
Mumit

building egcs-1.1.2-pre1 on cygwin-b20.1

[tprince]

As the cygwin target is still officially unsupported, I'm not sending
this to egcs-bugs.  Still, I must say the work which has gone into
making egcs workable on Windoze is much appreciated.

1.  Mumit Khan's egcs-1.1.1 patches work cleanly on a fresh
expansion of the 1.1.2-pre1 tarball, and are needed to avoid the
"multiple definition" errors when linking with libstdc++, and to
make libf2c work on W95.  The most recent development
snapshot seems to have cured the "multiple definition" problem
without needing such patches.  I haven't checked whether there
are other reasons remaining why they're needed.  I've been
testing the lib2c stuff with my correction to Mumit's correction.

2.  Mumit's advice to configure --host=i586-cygwin32 is
important, particularly if using pre-cygwin-b20.2 snapshots.  On
W95, it's necessary to symlink the target directories to the
i586-pc-cygwin32 default counterparts; this takes care of the
tendency of configure to ignore the specifications and take the
default at times.  Also necessary, at least on W95, are symlinks
to make appropriate files appear in /usr/include and /usr/lib.

3. make bootstrap-lean runs well on NT4/SP3, if properly
configured.  On W95, I have not been able to complete a
bootstrap, but a plain make runs well.  Current development
snapshots do OK with bootstrap on W95; they stop right before
compare-lean, but the rest may be complete successfully with
intervention.

4.  configure on W95 fails to recognize texinfo as an unsupported
directory.  This is the first time I've ever had this problem.  The
associated problem of having to do 'make -k install' because
install does not accept an unbuilt texinfo or chill is still with us,
regardless of which decision configure has made.

5.  'make -k install' doesn't run automatically into the library
installations.  On W95, it's necessary to go into each of these
directories and run install there.   On NT, it may be necessary to
start by running configure individually in each of these
directories.  Failure to do this will give you broken g++ and g77
libraries.  This seems to be caused by the inability of Windoze to
deal with aborted recursive makes.  This happens both with
cygwin-b20.1 and pre-b20.2.  egcs Makefile seems to be full of
these recursive makes which are expected to abort.

6.  On NT4, there are many redundant re-makes.  This may be
caused by the randomness of the 2 low-order bits of Windoze file
time-stamps.  It reminds me of being on jury duty, trying to guess
whether cygwin should mask out the random bits in an attempt
to present a monotonic time-stamp, or whether configure should
accept a certain level of tolerance.  W95 has the same
non-monotonicity, but it doesn't prolong the configure and build.

7. testsuite runs up to a point.  libstdc++, gcc, g++, and g77
compile-only tests work under cygwin-b20.1 on NT and b20.2 on
W95.  Execute tests don't work on NT, but do on W95/b20.2, until
an un-recoverable crash occurs.

8.  x86 performance with -Os -malign-double
-march=pentiumpro is quite satisfactory, especially on
i686-pc-linux-gnulibc1.  It's generally in between the
performance of lf90 and lf95, and better than the NAG f95 beta
(unless you plug in egcs as a back end).  On hppa and irix, the
development snapshots give faster running code, but currently
have disabling g77 bugs.  Also, the development snapshots are
more likely to give good performance with -O2 on x86.
Dr. Timothy C. Prince
Consulting Engineer
Solar Turbines, a Caterpillar Company
alternate e-mail: tprince@computer.org

           To:                                              INTERNET - IBMMAIL

Re: building egcs-1.1.2-pre1 on cygwin-b20.1

[Mumit Khan]

On Fri, 19 Feb 1999 tprince@cat.e-mail.com wrote:

> As the cygwin target is still officially unsupported, I'm not sending
> this to egcs-bugs.  Still, I must say the work which has gone into
> making egcs workable on Windoze is much appreciated.
> 
> 1.  Mumit Khan's egcs-1.1.1 patches work cleanly on a fresh
> expansion of the 1.1.2-pre1 tarball, and are needed to avoid the
> "multiple definition" errors when linking with libstdc++, and to
> make libf2c work on W95.  The most recent development
> snapshot seems to have cured the "multiple definition" problem
> without needing such patches.  I haven't checked whether there
> are other reasons remaining why they're needed.  I've been
> testing the lib2c stuff with my correction to Mumit's correction.

I ran the testsuite a few days ago after pre1 into my local tree, and
so far no regressions. In fact, all the C++ testsuite false negatives
are gone.

The multiple definition problems are still there, just harder to tickle.
Jason has added quite a few linkage patches to the dev tree, so 1.2 
should be better in this respect.

I've added your libf2c correction as well and will be in my binary 
release right after 1.1.2 comes out.

As for the bootstrap errors, I'll try it out on an NT and Win9x and 
see if I can duplicate your problem.

Thanks very much for the detailed feedback.

Regards,
Mumit