This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: EGCS-970929 and GNAT-3.10p?
- To: Joel Sherrill <joel at OARcorp dot com>
- Subject: Re: EGCS-970929 and GNAT-3.10p?
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Thu, 16 Oct 1997 09:51:43 -0600
- cc: Greg Galloway <gregg at eoeml dot gtri dot gatech dot edu>, egcs at cygnus dot com
- Reply-To: law at cygnus dot com
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