Re: GNAT nightmarre

Re: GNAT nightmarre

[Robert Dewar]

> In my case, I had to get rid of any existing GNAT compiler (I
> described that situation in a previous message this night) even very
> recent ones.


You can't really mean that, since as Richard points out, you must have
a GNAT compiler around to compile GNAT, and the only requirement is 
that this GNAT compiler you have around must be recent enough to do
the bootstrap, and you must see a consistent version of the compiler
and its binder on the path.

Re: GNAT nightmarre

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| > In my case, I had to get rid of any existing GNAT compiler (I
| > described that situation in a previous message this night) even very
| > recent ones.
| 
| 
| You can't really mean that,

Sure I do mean it.  Witnesses: I was only able to have
maintainer-scripts/gcc_release run normally only -after- removing
*all* instances of GNAT compilers from my $PATH.  That was not a dream.

The official documentation even mentions that you need either a GNAT
compiler *or* GCC-3.x.

-- Gaby

Re: GNAT nightmarre

[Alexandre Oliva]

On Jan 28, 2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:

> dewar@gnat.com (Robert Dewar) writes:
> | > In my case, I had to get rid of any existing GNAT compiler (I
> | > described that situation in a previous message this night) even very
> | > recent ones.
> | 
> | 
> | You can't really mean that,

> Sure I do mean it.  Witnesses: I was only able to have
> maintainer-scripts/gcc_release run normally only -after- removing
> *all* instances of GNAT compilers from my $PATH.

If you don't have an existing GNAT compiler, the build machinery
disables building of GNAT.  Perhaps that's why it worked for you?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: GNAT nightmarre

[Gabriel Dos Reis]

Alexandre Oliva <aoliva@redhat.com> writes:

| On Jan 28, 2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| 
| > dewar@gnat.com (Robert Dewar) writes:
| > | > In my case, I had to get rid of any existing GNAT compiler (I
| > | > described that situation in a previous message this night) even very
| > | > recent ones.
| > | 
| > | 
| > | You can't really mean that,
| 
| > Sure I do mean it.  Witnesses: I was only able to have
| > maintainer-scripts/gcc_release run normally only -after- removing
| > *all* instances of GNAT compilers from my $PATH.
| 
| If you don't have an existing GNAT compiler, the build machinery
| disables building of GNAT.  Perhaps that's why it worked for you?

That is curious because I got a working GNAT compiler both
  1) by manual build as expained in the documentation
  2) automated build as per contrib/gcc_build (I verified)

-- Gaby

Re: GNAT nightmarre

[Michael Matz]

Hi,

On 28 Jan 2003, Gabriel Dos Reis wrote:

> | > Sure I do mean it.  Witnesses: I was only able to have
> | > maintainer-scripts/gcc_release run normally only -after- removing
> | > *all* instances of GNAT compilers from my $PATH.
> |
> | If you don't have an existing GNAT compiler, the build machinery
> | disables building of GNAT.  Perhaps that's why it worked for you?
>
> That is curious because I got a working GNAT compiler both
>   1) by manual build as expained in the documentation
>   2) automated build as per contrib/gcc_build (I verified)

The point is: without a GNAT compiler anywhere reachable by the build
process the .adb files in gcc/ada/ can't be built.  Because those
constitute a good part of the Ada compiler you can't build that compiler
without having GNAT already somewhere.  If you removed _all_ GNAT's from
your system you simply can't have built a GNAT compiler, there is simply
no possibility to do that.  What could have happened though is, that you
only changed your $PATH to "hide" your GNAT, and that $PATH got reset
somehow (e.g. through shell startup scripts), so that it was found again.

What also could be possible (it can't be ruled out by the information you
gave) is, that you already built an intermediate Ada compiler, until it
broke the build process, then removed your system GNAT, but did fail to
remove the intermediate version, which later could have been used.  Hard
to tell.  Possibly you have the builddir in your path or so.  Whatever, if
you have nowhere a GNAT, and start from a clean build dir, you can't have
ended up with any GNAT version.  Look in your buildlogs, which gnat was
used to compile all the .adb files in gcc/ada/ ?  And you started from a
clean build dir?


Ciao,
Michael.

Re: GNAT nightmarre

[Gabriel Dos Reis]

Michael Matz <matz@suse.de> writes:

[...]

| What also could be possible (it can't be ruled out by the information you
| gave) is, that you already built an intermediate Ada compiler, until it
| broke the build process, then removed your system GNAT, but did fail to
| remove the intermediate version, which later could have been used. 

This is not possible because I removed the directory containing the
build -- maintainer-scripts/gcc_release refuses to build the source
if there is a directory it would like to make.

[ I will tell you the rest in a moment. ]

-- Gaby

Re: GNAT nightmarre

[Robert Dewar]

well let's wait till we figure out what is going on with Gaby's problems
then we can sort out both the procedure and the documentation. Geert is
looking into this right now.

Re: GNAT nightmarre

[Gerald Pfeifer]

On Tue, 28 Jan 2003, Robert Dewar wrote:
> So that's what the documentation should say.

Well, would you mind checking gcc/doc/install.texi and making updates
you consider necessary/suitable? ;-)

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: GNAT nightmarre

[Robert Dewar]

Well the issue is simply that you need a gnat compiler that can do the
bootstrap. Whether this comes as part of GCC-3.x or not is not the issue.
So that's what the documentation should say.

Re: GNAT nightmarre

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| > The official documentation even mentions that you need either a GNAT
| > compiler *or* GCC-3.x.
| 
| OK, but just as GCC-3.x contains the g++ compiler and the gnu c compiler,
| it contains the gnat compiler, so this terminology is a little confusing.

Do you see a better terminology?

-- Gaby

Re: GNAT nightmarre

[Robert Dewar]

> The official documentation even mentions that you need either a GNAT
> compiler *or* GCC-3.x.

OK, but just as GCC-3.x contains the g++ compiler and the gnu c compiler,
it contains the gnat compiler, so this terminology is a little confusing.

Re: GNAT nightmarre

[Gabriel Dos Reis]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

|     Actually, just the opposite is true.  I spent 6 six hours figuring
|     that out.  If I have an existing compiler in my $PATH then I get the
|     infamous error -- see my previous messages.
| 
| But if you *don't* have an existing compiler in your $PATH, how can 
| you compile the Ada files that comprise GNAT?

The way it is documented on http://gcc.gnu.org/buidl.html ?

Again, I didn't dream :-)

-- Gaby

Re: GNAT nightmarre

[Richard Kenner]

    Actually, just the opposite is true.  I spent 6 six hours figuring
    that out.  If I have an existing compiler in my $PATH then I get the
    infamous error -- see my previous messages.

But if you *don't* have an existing compiler in your $PATH, how can 
you compile the Ada files that comprise GNAT?

Re: GNAT nightmarre

[Geert Bosch]

On Tuesday, Jan 28, 2003, at 08:54 America/New_York, Gabriel Dos Reis 
wrote:
> In fact, I suspect that it is the lack of explicit qualification of
> gnatbind that leads to the nightmarra I got this night :-(

I think so. We really should build it as xgnatbind and then rename it
during install.

Re: GNAT nightmarre

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| > I don't dispute the consistency requirement, it is very natural.  It is
| > *the way the tools are invoked* that imply more (unintended)
| > requirements that I find unnatural.
| 
| Can you be a little clearer about what these " more (unintended) requirements"
| are?

In my case, I had to get rid of any existing GNAT compiler (I
described that situation in a previous message this night) even very
recent ones.

-- Gaby

Re: GNAT nightmarre

[Gabriel Dos Reis]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

|   1) The way the GNAT build infrastructure is set up requires that
|      each time one has to build a GNAT compiler then, one has to get rid of
|      any existing compiler from $PATH.  
| 
| In general, that's not true.  In fact, just the opposite is true: you *must*
| have a version of GNAT on $PATH or else you can't build the Ada
| files. 

Actually, just the opposite is true.  I spent 6 six hours figuring
that out.  If I have an existing compiler in my $PATH then I get the
infamous error -- see my previous messages.

In order to get a bootstrap, I had to dicth any existing GNAT compiler
from my system.  Only after that could I bootstrap GNAT.

There is just another GNATS PR filled relating the same problem.

| I
| routinely build in that way (though I haven't checked to see if there are any
| relevant procedural differences in HEAD).  What *is* true is that you can't
| build with a very old version of GNAT, but that doesn't look like your
| problem.
| 
| I suspect your problem actually might be that you have "." in your path,
| which won't work and is a bad idea for other (security) reasons anyway.

No, I don't have . in my $PATH.

And how do you explain the fact I had to remove the OS-vendor supplied
GNAT compiler (1.33p) installed in /usr/bin/ before completing a bootstrap?

| However, it might indeed be good to build gnatbind as xgnatbind for the same
| reasons that we build gcc as xgcc (which would also solve that problem).
| 
|      On some systems that is
|      impractical because some OS vendors ship GNAT 1.33p which is
|      installed under /usr/bin (where most utilities also reside).  And
|      not all users have the ability/right to get rid of that
|      existing compiler.
| 
| Right.  If you have a too-old compiler, all you can do is install a new
| one someplace and put it earlier in your $PATH.
| 
|       2) The existence of a compiler on a system should not preclude the
|          build of a new one.  That is certainly true for C, C++, Java,
|          Objective-C. 
| 
|     In fact, I suspect that it is the lack of explicit qualification of
|     gnatbind that leads to the nightmarra I got this night :-(
| 
| That coupled with "." in your path, I think.

Again, I don't have "." in my path.

-- Gaby

Re: GNAT nightmarre

[Robert Dewar]

>   1) The way the GNAT build infrastructure is set up requires that
>      each time one has to build a GNAT compiler then, one has to get rid of
>      any existing compiler from $PATH.  On some systems that is
>      impractical because some OS vendors ship GNAT 1.33p which is
>      installed under /usr/bin (where most utilities also reside).  And
>      not all users have the ability/right to get rid of that
>      existing compiler.

Well certainly in our environment we do not have to do any such thing, it
is normal on my machine to have dozens of versions of GNAT around, and to
be able to build whatever I want without a problem, so this is certainly
a solvable problem.

Re: GNAT nightmarre

[Robert Dewar]

> I don't dispute the consistency requirement, it is very natural.  It is
> *the way the tools are invoked* that imply more (unintended)
> requirements that I find unnatural.

Can you be a little clearer about what these " more (unintended) requirements"
are?

Certainly we all agree that it should be easy to build and we should try
to 

a) find out what you are running into
b) bulletproof the make file if possible from this error

Re: GNAT nightmarre

[Richard Kenner]

  1) The way the GNAT build infrastructure is set up requires that
     each time one has to build a GNAT compiler then, one has to get rid of
     any existing compiler from $PATH.  

In general, that's not true.  In fact, just the opposite is true: you *must*
have a version of GNAT on $PATH or else you can't build the Ada files.  I
routinely build in that way (though I haven't checked to see if there are any
relevant procedural differences in HEAD).  What *is* true is that you can't
build with a very old version of GNAT, but that doesn't look like your
problem.

I suspect your problem actually might be that you have "." in your path,
which won't work and is a bad idea for other (security) reasons anyway.
However, it might indeed be good to build gnatbind as xgnatbind for the same
reasons that we build gcc as xgcc (which would also solve that problem).

     On some systems that is
     impractical because some OS vendors ship GNAT 1.33p which is
     installed under /usr/bin (where most utilities also reside).  And
     not all users have the ability/right to get rid of that
     existing compiler.

Right.  If you have a too-old compiler, all you can do is install a new
one someplace and put it earlier in your $PATH.

      2) The existence of a compiler on a system should not preclude the
         build of a new one.  That is certainly true for C, C++, Java,
         Objective-C. 

    In fact, I suspect that it is the lack of explicit qualification of
    gnatbind that leads to the nightmarra I got this night :-(

That coupled with "." in your path, I think.

Re: GNAT nightmarre

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| > OK, it seems like we're making some progress (althought I don't find
| > the above requirements quite natural, but that is another story).
| 
| Well I am not sure why you would find these requirements unnatural. 

I don't want to side track the main issue, however here are my
justifications: 

  1) The way the GNAT build infrastructure is set up requires that
     each time one has to build a GNAT compiler then, one has to get rid of
     any existing compiler from $PATH.  On some systems that is
     impractical because some OS vendors ship GNAT 1.33p which is
     installed under /usr/bin (where most utilities also reside).  And
     not all users have the ability/right to get rid of that
     existing compiler.

  2) The existence of a compiler on a system should not preclude the
     build of a new one.  That is certainly true for C, C++, Java,
     Objective-C. 

In fact, I suspect that it is the lack of explicit qualification of
gnatbind that leads to the nightmarra I got this night :-(

| The
| compiler generates ALI files which the binder must read. The format of
| these files typically changes from version to version, so you must use
| consistent versions of the compiler and binder.

I don't dispute the consistency requirement, it is very natural.  It is
*the way the tools are invoked* that imply more (unintended)
requirements that I find unnatural.

-- Gaby

Re: GNAT nightmarre

[Robert Dewar]

> OK, it seems like we're making some progress (althought I don't find
> the above requirements quite natural, but that is another story).

Well I am not sure why you would find these requirements unnatural. The
compiler generates ALI files which the binder must read. The format of
these files typically changes from version to version, so you must use
consistent versions of the compiler and binder.

Re: GNAT nightmarre

[Gabriel Dos Reis]

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

Re: GNAT nightmarre

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| > 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?
| 
| Yes, that does mean that, you must not put the new gnatbind onto your
| path until the new compiler is there to match it. It is critical that
| the compiler and binder always be of the same generation. But I am not
| 100% sure of what your procedure is, so it is still not clear where
| the problem lies.

OK, it seems like we're making some progress (althought I don't find
the above requirements quite natural, but that is another story).

  1) I deleted any incarnation of GNAT from my PATH.  Then a manual
     build was successful.   Phew.

  2) I erased the build directory, issued

       maintainer-script/gcc_release -r 3.2.2 -u gdr all
   
     and got back the failure point.  I don't know what to think.

-- Gaby

Re: GNAT nightmarre

[Geert Bosch]

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.
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.
I'll try to reproduce your issue tomorrow.

   -Geert

Re: GNAT nightmarre

[Robert Dewar]

> 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?

Yes, that does mean that, you must not put the new gnatbind onto your
path until the new compiler is there to match it. It is critical that
the compiler and binder always be of the same generation. But I am not
100% sure of what your procedure is, so it is still not clear where
the problem lies.

> ell, I hope invoking contrip/gcc_build is considered normal build...

Certainly seems like it should be ...

Re: GNAT nightmarre

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| > gnatbind -C -I- -I. -I/home/gdr/gcc-3.2.2-20030128/gcc-3.2.2-20030128/gcc/ada -o b_gnat1.c -n gnat1drv.ali
| > fatal error: file gnat1drv.ali is incorrectly formatted
| > make sure you are using consistent versions of gcc/gnatbind
| > 16.  
| 
| What this error message means is that the gnatbind you are using is
| inconsistent with the compiler used to build the input to gnatbind.

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?

| This of course should never happen, and does not happen in a normal
| build, so something strange is going on. Not easy to guess what from
| your description.

Well, I hope invoking contrip/gcc_build is considered normal build...

-- Gaby

Re: GNAT nightmarre

[Robert Dewar]

> gnatbind -C -I- -I. -I/home/gdr/gcc-3.2.2-20030128/gcc-3.2.2-20030128/gcc/ada -o b_gnat1.c -n gnat1drv.ali
> fatal error: file gnat1drv.ali is incorrectly formatted
> make sure you are using consistent versions of gcc/gnatbind
> 16.  

What this error message means is that the gnatbind you are using is
inconsistent with the compiler used to build the input to gnatbind.
This of course should never happen, and does not happen in a normal
build, so something strange is going on. Not easy to guess what from
your description.

GNAT nightmarre

[Gabriel Dos Reis]

Hi,
I've been banging my head against the GNAT wall for some hours.

First, mainainers-script/gcc_release died because of:

gnatbind -C -I- -I. -I/home/gdr/gcc-3.2.2-20030128/gcc-3.2.2-20030128/gcc/ada -o b_gnat1.c -n gnat1drv.ali
fatal error: file gnat1drv.ali is incorrectly formatted
make sure you are using consistent versions of gcc/gnatbind
16.  

Then, I erased everything (build-dir) and followed step by step our
Fine Manual http://gcc.gnu.org/install/build.html in order to build a
a GNAT compiler. Fine.  I installed everything in my path.  The base
source was the gcc-3_2-branch.  Then I restarted gcc_release... which
dies exactly at the previous same point.  I tried a manual build: No way.

So my question: is there any way to get GNAT built (with the gcc_release
script)?  Why is to painful to build GNAT?

-- Gaby