This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GNAT nightmarre
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Geert Bosch <bosch at gnat dot com>
- Cc: dewar at gnat dot com (Robert Dewar), gcc at gcc dot gnu dot org
- Date: 28 Jan 2003 06:53:59 +0100
- Subject: Re: GNAT nightmarre
- Organization: Integrable Solutions
- References: <18799293-3282-11D7-9E39-00039344BF4A@gnat.com>
Geert Bosch <bosch@gnat.com> writes:
| On Tuesday, Jan 28, 2003, at 00:18 America/New_York, Gabriel Dos Reis
| wrote:
|
| > Does that mean that if I have an instance of gnatbind, *freshly built*,
| > in my PATH and I'm building a new GNAT compiler (same source as the
| > one previously built gnatbind), then inevitably I'll get into trouble?
| >
|
| When doing the first stage of a bootstrap of GNAT version Y using
| version X
| as a bootstrap compiler, then gnatbind version X must be used, and not
| gnatbind version Y. A similar requirement exists for the C compiler
| and the
| "gcc" driver, but in that case there is less possibility for confusion
| as
| the executable is names "xgcc" and renamed to "gcc" during installation.
More importantly, during boostrap, the "xgcc" driver is referred
to using relative path, i.e. ./xgcc or stagte1/xgcc, which leaves no
room for any mismatch. I believe an equivalent form for the GNAT
bootstrap machinery would be a great improvement over the current
situation.
| This might be a good idea for GNAT too, but that is not the case
| currently.
| Still I don't see how you ended up using inconsistent gnat1/gnatbind
| binaries.
What is annoying me is why a manual bootstrap is successful while a
bootstrap with the dedicated script isn't. Somehow, the machinery is
finding different versions of C compiler and GNAT driver if I
understand your explanation coccrectly.
| I'll try to reproduce your issue tomorrow.
OK.
Only the GNAT issue is holding the pre-release.
-- Gaby