This is the mail archive of the
mailing list for the GCC project.
Re: libada multilb advice request
Richard Guenther wrote:
On 7/26/07, Joel Sherrill <firstname.lastname@example.org> wrote:
I fixed something like 29127 years ago in gnatmake.
Richard Guenther wrote:
> On 7/26/07, Joel Sherrill <email@example.com> wrote:
>> I am taking a stab at getting libada to build multilib
>> and I just don't seem to grok the magic. I am doing this
>> for RTEMS but the target shouldn't matter as long as
>> it is multilib'ed. Instructions for building GNAT/RTEMS are at
>> This works well except the Ada libraries are not multilibed.
>> I started by adding --enable-libada --enable-multilib
>> to our configures but that didn't do anything to libada.
>> As best I can tell, the top level configure/Makefile
>> magic is in place for libada to be multilib'ed but I
>> don't even see the multilib directory structure getting
>> I have tried to edit libada/configure.ac and libada/Makefile.in
>> based upon the multilib magic I see in other top level
>> directories. So far no luck on even getting the multilib
>> structure generated in the build tree. The attached patch
>> has what I have so far along with the other RTEMS patches to 4.2.0.
>> I would really appreciate some hints. This is just
>> black magic.
> Ada is not multilib capable.
What exactly does you mean by this statement? I know the
current build structure doesn't build libada multilib and I
want to fix that. That was what the attached patch attempted
Is it explicitly disabled somewhere I missed?/
Embedded users whose target CPU doesn't match the
default CPU model end up custom building the
library. I want to get libada multilib'ed so this burden
I was trying to say that even if you manage to build multilibs for
the current gnat driver does not know how to use them. In fact, the
gnat driver(s) behave sufficiently different than all other gcc frontends
which results in funny bugs like PR29127 and PR30560.
I will look into both of them if I get the multilib working. Those
bugs do not appear to be holding up multilib'ing libada as best I
(I certainly applaud any efforts to bring ada more in-line with the other
frontends in this regard)
Any suggestions on what might be preventing the configure/build from
even making multilib build directories for libada. Is there any explicit
disable I am missing?