Laurent GUERBY wrote:
Joel did test (a previous iteration of) this patch on many RTEMS
multilibed targets and it worked (RTEMS system.ads already use Standard
attributes to be portable so no issue there).
I thought I would follow up with some details. I tested
on mips, powerpc, x86, and spar
Laurent GUERBY wrote:
On Fri, 2008-07-25 at 10:55 +, Joseph S. Myers wrote:
i686-linux-gnu --enable-targets=all and x86_64-linux-gnu are equivalent,
differing only in whether the default is 32-bit or 64-bit. Do you select
the right files for both multilibs of i686-linux-gnu, as well as for
On Fri, 2008-07-25 at 10:55 +, Joseph S. Myers wrote:
> i686-linux-gnu --enable-targets=all and x86_64-linux-gnu are equivalent,
> differing only in whether the default is 32-bit or 64-bit. Do you select
> the right files for both multilibs of i686-linux-gnu, as well as for both
> multilibs
On Fri, 25 Jul 2008, Laurent GUERBY wrote:
> The attached patch implements Arnaud suggestion of changing the arch
> to select the appropriate source (done and tested for x86_64-linux only
> for now) and doesn't touch anymore system-*.ads.
As a general comment on x86_64 handling, not having checke
On Fri, 2008-07-25 at 09:35 +0200, Arnaud Charlet wrote:
> > I think this will help review and this is useful change on its own,
> > should I test and submit this first part separately?
>
> Yes, although I'd wait for the tuples branch and gcc-interface restructuration
> which will happen end of ju
>>> As an alternative, people that don't want multilibbed libada can not use
>>> libada altogether. More on this in a second.
>>
>> Still not clear to me what you mean here.
>
> I was thinking about using --disable-libada and instead using the "make -C
> gcc gnatlib" target. You will get no m
I volunteer to check if there is support for
--enable-multilib=libstdc++-v3,libjava and if not add it. Unfortunately,
--disable-multilib=ada cannot work (because --disable-xxx is the same as
--enable-multilib=no).
Does that mean that libgcc is implicitely multilibed if --enable-multilib=
is
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> Arnaud Charlet wrote:
>>> Yes I volunteer. We're in stage1 so we have some time to sort out
>>> reported issues before release.
>>
>> OK. I'm still concerned that there is no simple fallback for all targets
>> that will break, except for --disable-multil
Thanks Paolo for your explanations, things are getting much clearer!
> I volunteer to check if there is support for
> --enable-multilib=libstdc++-v3,libjava and if not add it. Unfortunately,
> --disable-multilib=ada cannot work (because --disable-xxx is the same as
> --enable-multilib=no).
Doe
Arnaud Charlet wrote:
Yes I volunteer. We're in stage1 so we have some time to sort out
reported issues before release.
OK. I'm still concerned that there is no simple fallback for all targets
that will break, except for --disable-multilib which is too strong since
it impacts other languages.
> Yes I volunteer. We're in stage1 so we have some time to sort out
> reported issues before release.
OK. I'm still concerned that there is no simple fallback for all targets
that will break, except for --disable-multilib which is too strong since
it impacts other languages.
I'd be much more conf
On Fri, 2008-07-25 at 09:00 +0200, Arnaud Charlet wrote:
> > 1/ Ada multilib build is enabled unless --disable-multilib is used in
> > configure: this means that the Ada build has more opportunity to fail
> > because of code generation bugs or libada source selection issue, but in
> > this later ca
> 1/ Ada multilib build is enabled unless --disable-multilib is used in
> configure: this means that the Ada build has more opportunity to fail
> because of code generation bugs or libada source selection issue, but in
> this later case it will be a only few lines in gcc/ada/Makefile.in to
> fix it
13 matches
Mail list logo
