Re: EGCS-970929 and GNAT-3.10p?

[Joel Sherrill <joel at OARcorp dot com>]

> Well, if you remember what went wrong I might be able to provide some
> assistance now (I don't think I saved that message, I guess I could go
> wander the archives...).

I have just finished a testing sweep trying to get gnat/rtems up to date
on a bunch of tools and see that it still worked on at least the sparc.  I
will attack building 3.10p on egcs RSN.  I have one problem with gnat
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.  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.
Best I could tell no other language subdirectory used target_alias.  I
have had to hand edit the generated ada/Makefile.

Any one have any ideas why this substitution might be broken?

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.

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

> BTW -- is it just me, or is the Ada compiler extremely slow?

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.  

> This was mostly a proof of concept and to give me some home grown gnat
> binaries for bootstrapping purposes later.  I'm not going to try to
> integrate GNAT into egcs right now (though we do want it long term).

Public gnat's are not released very often so this should not be that much
trouble.  No development snapshots are publicly available.  If I ever give
anything other than that impression, please slap me around. :)

> When we do start thinking about integrating GNAT, the big issues will be:
> 
>   * GNAT is written in Ada, and thus requires GNAT binaries to bulid itself.

Yes.  

>   * The build process isn't exactly "make; make install" :-)  We'll have
>   to pull out the runtime and figure out how to deal with gnattools.  I
>   suspect there'll be problems with GNAT in cross build environments too.

The cross procedure is different and requires some changes to makefiles
and tools.  I am trying to work these out.

--joel