EGCS-970929 and GNAT-3.10p?

[Jeffrey A Law]

  In message < Pine.BSF.3.96.971016075832.13079A-100000@vespucci.advicom.net >you write:
  > 3.10p and the early August  testgcc snapshot I was working with.  The
  > substitution in Makefile.in as follows:
  > 
  > target=
  > target_alias=
  > 
  > Gets botched for target alias.
Hmmm, my gcc/ada/Makefile doesn't have a reference to target_alias:

% grep target_alias Makefile
% grep target= Makefile
target=hppa1.1-hp-hpux10.20


   > Both lines end up with target= on the LHS.
  > I am not an autoconf expert but it looks like the substitution in the
  > language subdirectories is done differently form the main gcc/Makefile.in.
Quite possible -- that stuff has changed a lot recently.

  > FYI the vanilla gnat source does not have any references to target_alias,
  > program_prefix, or program_transform_name.  That was part of ewhat I was
  > working on.
Maybe that's why I don't have target_alias in the generated Makefile :-)

Yes, the lack of prefix & transform name will be an issue we'll
have to settle.  Part of the generic "fix Ada for cross platforms"
problem.


  > > I started poking at gnat-3.10p with egcs a short while ago -- I got
  > > gnat1 and gnattools built on the PA.  It then died building the
  > > library due to a buglet in the gcc-2.7.2 PA binaries provided by
  > > the GNAT folks.
  > 
  > I have noticed people in the past griping about the PA.  
It should be noted that once I got the first egcs based gnat binary running
it would successfully bootstrap with -O2 or no optimization -- no released
version of gnat can do that as far as I know! (some ada files have to be built
with optimization and others without)

Many of the PA gnat problems can be traced back to Kenner refusing to
fix some C code in the Ada front end which has undefined ANSI behavior.

  > It probably looks that way since you probably have no idea how much work
  > it is doing. :) It is not really that slow as far as Ada compilers go.  
:-) :-)  It certainly seems slow to me :-)


jeff