* Re: RFC/Ada: removal of $(ADAC)
@ 2003-05-13 14:36 Roger Sayle
2003-05-13 19:00 ` Geoff Keating
0 siblings, 1 reply; 5+ messages in thread
From: Roger Sayle @ 2003-05-13 14:36 UTC (permalink / raw)
To: gcc; +Cc: Richard Kenner, Zack Weinberg
Hi Richard,
Well you did request comments!
I must admit that I had reason to resort to needing $(ADAC) as
recently as last week. Whilst you may argue its was caused by
user-error, I think it may be a fairly common mistake.
If with the FSF tree, on a system with an installed GNAT in /usr/bin,
you type the innocent "configure", "make bootstrap" and "make install",
you can get the system into an inconsistent state requiring $(ADAC)
to dig you out.
The problem is that by default make builds and installs gnat but not
"gnatlib_and_tools" from the gcc/ada subdirectory. I managed to
install a 3.4 /usr/local/bin/gcc and /usr/local/bin/gnat on a RedHat
8.0 system, however the next time I tried a "configure", "make" and
"make install" the bootstrap failed. The configuration process
picked up my new 3.4 /usr/local/bin/gcc and /usr/local/bin/gnat,
but /usr/bin/gnatbind and /usr/bin/gnatmake for 3.2, which then
gives errors about files having the wrong versions.
My solution, using "ADAC=/usr/bin/gcc", to atleast bootstrap the
ada front-end, then manually build "gnatlib_and_tools" and install
them. But for some reason, I still had to install "gnatmake"
manually!
I haven't filed any of this as a bug report as the on-line
installation documentation describes all of it including both
the need to run "make gnatlib_and_tools" and how you may need
to use $(ADAC) if things get screwed up. So its a feature!
Perhaps once the irregularities building and installing the Ada
front-end's library and build tools is sorted out it may be reasonable
to remove support for $(ADAC). Until then, I'd recommend keeping it.
The good news however is that I can now regularly test the patches
that I submit to gcc-patches with all languages including Ada.
Roger
--
Roger Sayle, E-mail: roger@eyesopen.com
OpenEye Scientific Software, WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road, Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507. Fax: (+1) 505-473-0833
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RFC/Ada: removal of $(ADAC)
2003-05-13 14:36 RFC/Ada: removal of $(ADAC) Roger Sayle
@ 2003-05-13 19:00 ` Geoff Keating
0 siblings, 0 replies; 5+ messages in thread
From: Geoff Keating @ 2003-05-13 19:00 UTC (permalink / raw)
To: Roger Sayle; +Cc: Richard Kenner, Zack Weinberg, gcc
Roger Sayle <roger@www.eyesopen.com> writes:
> Hi Richard,
>
> Well you did request comments!
>
> I must admit that I had reason to resort to needing $(ADAC) as
> recently as last week. Whilst you may argue its was caused by
> user-error, I think it may be a fairly common mistake.
>
> If with the FSF tree, on a system with an installed GNAT in /usr/bin,
> you type the innocent "configure", "make bootstrap" and "make install",
> you can get the system into an inconsistent state requiring $(ADAC)
> to dig you out.
>
> The problem is that by default make builds and installs gnat but not
> "gnatlib_and_tools" from the gcc/ada subdirectory. I managed to
> install a 3.4 /usr/local/bin/gcc and /usr/local/bin/gnat on a RedHat
> 8.0 system, however the next time I tried a "configure", "make" and
> "make install" the bootstrap failed. The configuration process
> picked up my new 3.4 /usr/local/bin/gcc and /usr/local/bin/gnat,
> but /usr/bin/gnatbind and /usr/bin/gnatmake for 3.2, which then
> gives errors about files having the wrong versions.
This isn't user error, it's a known bug, ada/5910.
> My solution, using "ADAC=/usr/bin/gcc", to atleast bootstrap the
> ada front-end, then manually build "gnatlib_and_tools" and install
> them. But for some reason, I still had to install "gnatmake"
> manually!
>
>
> I haven't filed any of this as a bug report as the on-line
> installation documentation describes all of it including both
> the need to run "make gnatlib_and_tools" and how you may need
> to use $(ADAC) if things get screwed up. So its a feature!
No, it's just a well-documented bug.
Still, I think it should be fixed before we remove ADAC especially if
the installation documentation mentions it.
> Perhaps once the irregularities building and installing the Ada
> front-end's library and build tools is sorted out it may be reasonable
> to remove support for $(ADAC). Until then, I'd recommend keeping it.
I agree.
--
- Geoffrey Keating <geoffk@geoffk.org>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RFC/Ada: removal of $(ADAC)
@ 2003-05-13 15:52 Richard Kenner
0 siblings, 0 replies; 5+ messages in thread
From: Richard Kenner @ 2003-05-13 15:52 UTC (permalink / raw)
To: roger; +Cc: gcc
I'm not up to speed on the arguments for why this isn't the default.
Basically because no one has done it yet and that's because nobody has
figured out how to do it. I suspect part of that task is going to be the
splitting up of the files in the ada directory into those for the compiler
and those for the library, but it's tricky because the compiler needs to
use the library files when it's built.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RFC/Ada: removal of $(ADAC)
2003-05-13 15:21 Richard Kenner
@ 2003-05-13 15:50 ` Roger Sayle
0 siblings, 0 replies; 5+ messages in thread
From: Roger Sayle @ 2003-05-13 15:50 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
On Tue, 13 May 2003, Richard Kenner wrote:
> If with the FSF tree, on a system with an installed GNAT in /usr/bin,
> you type the innocent "configure", "make bootstrap" and "make install",
> you can get the system into an inconsistent state requiring $(ADAC)
> to dig you out.
>
> The problem is that by default make builds and installs gnat but not
> "gnatlib_and_tools" from the gcc/ada subdirectory.
>
> Right. You do need to do that.
I'm not up to speed on the arguments for why this isn't the default.
Enabling gcj builds libjava by default, and g++ builds libstdc++...
> My solution, using "ADAC=/usr/bin/gcc", to atleast bootstrap the ada
> front-end, then manually build "gnatlib_and_tools" and install them.
> But for some reason, I still had to install "gnatmake" manually!
>
> I'm not sure sure I understand how that helped, but why wouldn't simply
> using CC=/usr/bin/gcc have worked just as well?
Ah, OK. That may well have fixed the problem I was experiencing. At
the time I was focused on this being an ada specific problem, when I
came across the ADAC documentation in the installation instructions.
I withdraw my objections. Though the process wasn't as painless as
it could have been.
Roger
--
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RFC/Ada: removal of $(ADAC)
@ 2003-05-13 15:21 Richard Kenner
2003-05-13 15:50 ` Roger Sayle
0 siblings, 1 reply; 5+ messages in thread
From: Richard Kenner @ 2003-05-13 15:21 UTC (permalink / raw)
To: roger; +Cc: gcc
If with the FSF tree, on a system with an installed GNAT in /usr/bin,
you type the innocent "configure", "make bootstrap" and "make install",
you can get the system into an inconsistent state requiring $(ADAC)
to dig you out.
The problem is that by default make builds and installs gnat but not
"gnatlib_and_tools" from the gcc/ada subdirectory.
Right. You do need to do that.
My solution, using "ADAC=/usr/bin/gcc", to atleast bootstrap the ada
front-end, then manually build "gnatlib_and_tools" and install them.
But for some reason, I still had to install "gnatmake" manually!
I'm not sure sure I understand how that helped, but why wouldn't simply
using CC=/usr/bin/gcc have worked just as well?
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-05-13 19:00 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-13 14:36 RFC/Ada: removal of $(ADAC) Roger Sayle
2003-05-13 19:00 ` Geoff Keating
2003-05-13 15:21 Richard Kenner
2003-05-13 15:50 ` Roger Sayle
2003-05-13 15:52 Richard Kenner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).