Re: GNAT nightmarre

[kenner at vlsi1 dot ultra dot nyu dot edu (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.