Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-ID: <00c701c10c0c$7519a3c0$9865fea9@timayum4srqln4>
From: "Tim Prince" <tprince AT computer DOT org>
To: "ted byers" <ted DOT byers AT sympatico DOT ca>, <cygwin AT cygwin DOT com>
References: <002d01c10bd8$14caa1b0$7069e740 AT beak DOT com>
Subject: Re: Building gcc3.0 appears to have worked
Date: Fri, 13 Jul 2001 19:26:55 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "ted byers" <ted DOT byers AT sympatico DOT ca>
To: <cygwin AT cygwin DOT com>
Sent: Friday, July 13, 2001 1:12 PM
Subject: Building gcc3.0 appears to have worked


> Following the advice kindly provided by Mr Prince and Mr Kahn, it
appears
> that I have been able to get gcc 3.0 to compile.  However, I have a
couple
> questions.  Some of these may be due to the fact it has been a while
since I
> have used unix, so ...
>
> I observed the following errors that occured during the build, but
make
> appeared to ignore them.  Should I be concerned about them?
The missing g77 files at stage2 would be a problem.  I don't think
you're attempting to build cross
compiler components, and protoize/unprotoize/gcov appear to be broken in
the cygwin build,
and aren't needed.  enquire is a tool to build <limits.h> and <float.h>
in case you don't have
reliable pre-existing copies, but it hasn't been part of the build for
years.  On cygwin, it
will disagree on the <float.h> entries for long double, unless you set
the precision mode to 53 bits.
>
> mv: cannot stat `s-crt0': No such file or directory
> mv: cannot stat `gcc-cross.exe': No such file or directory
> mv: cannot stat `cc1obj.exe': No such file or directory
> mv: cannot stat `enquire.exe': No such file or directory
> mv: cannot stat `protoize.exe': No such file or directory
> mv: cannot stat `unprotoize.exe': No such file or directory
> mv: cannot stat `collect2.exe': No such file or directory
> mv: cannot stat `*.[0-9][0-9].*': No such file or directory
> mv: cannot stat `*.[si]': No such file or directory
> mv: cannot stat `g++-cross.exe': No such file or directory
> mv: cannot stat `g77-cross.exe': No such file or directory
> make[2]: [stage2-start] Error 1 (ignored)
> mv intl/*.o stage2/intl
>
>
>
> mv: cannot stat `g77spec.o': No such file or directory
> mv: cannot stat `g77version.o': No such file or directory
> make[2]: [f77.stage2] Error 1 (ignored)
> make[2]: Leaving directory `/home/Bted/Objects/gcc'
>
> ===============end of build errors=======================
>
> I also ran the test suite and, ten hours later, observed the following
> results
>
> === gcc Summary ===
>
> # of expected passes 15203
> # of unexpected failures 9
> # of unexpected successes 3
> # of expected failures 85
> # of unresolved testcases 1
> # of unsupported tests 25

> runtest completed at Sat Jul  7 02:30:31 2001
>
>
> === g77 Summary ===
>
> # of expected passes 281
> # of unexpected failures 334
> # of untested testcases 326
> /home/Bted/Objects/gcc/g77 g77 version 3.0 (Fortran Frontend version
0.5.26
> 20010617 (experimental))
>
>
> I suppose that this means that gcc 3.0, as built on my system is
reasonably
> usable.  But I would also suppose that g77 is so seriously broken as
to be
> unusable.  Would that be correct?
Yes, the gcc results look good, but all the g77 tests ought to pass.
You might
check whether the libf2c got built correctly; you can blow away that
subdirectory of
your build directory and rebuild just that part.  If it doesn't
configure itself fully
automatically, you can cd into it and run gcc/libf2c/configure.Assuming
that your build
went through make compare successfully, that could be all that is wrong.
>
> Also, when I query gcc from the cygwin bash prompt, it seems to think
it is
> gcc 2.95.?, so it would seem that although the binaries were built and
put
> where I configured them to be put, it is the old ones that I will get
when I
> compile from the bash prompt.  So the question is, how can I control
which
> version of gcc I am using, assuming I will want to leave both intact
(for
> testing purposes), and ensure that each searches its own include path,
and
> this without having to type the full path to each set of binaries?

You will need to supply the full path, or an alias.   You could try
configuring the new
compiler for --prefix=/usr and, after installing it, see whether you can
select the old one
by e.g.
gcc -V2.95.2
but that is unlikely to work, at least for g++, where the changes are so
great.  On my cygwin
installations, /usr/local/bin/gcc is found by default over /usr/bin/gcc
or /bin/gcc, which is
contrary to normal expectation from other OS installations.  I have
always wanted to use
separate installations, although I do usually over-write the binutils,
as I expect fully that
some parts of my new installation will be broken.  So, if I want to
revert to the standard
cygwin binutils, I must expand the tar file, and then re-install the new
one if I wish.  I have
needed that only when I want to run the original g++.

>
> Ted
>
> R.E. Byers
> ted DOT byers AT sympatico DOT ca


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/