This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: [build, ada] Centralize PICFLAG configuration
Arnaud Charlet <charlet@adacore.com> writes:
>> Ok, I see. Perhaps gcc/ada could be disentangled and those files
>> exclusively or primarily used for libgnat/libgnarl moved over to libada,
>> and referenced from there for the host build?
>
> That would require some delicate work on AdaCore's side, so wouldn't be
> helpful in the short term (rather harmful actually).
I wasn't suggesting this as a short-term project, but given the clutter
of gcc/ada might be a good idea longer term.
>> > So passing PICFLAG down to the gcc/ada/gcc-interface Makefile and not
>> > just via libada/Makefile is indeed important.
>>
>> This seems to be easy: unless I'm mistaken, it should suffice to just
>> call GCC_PICFLAG in gcc/configure.ac and substitute the result in
>> gcc/ada/gcc-interface/Makefile.in. What's the best way to test this?
>
> You can e.g. add some dummy target in the Makefile that will echo
> the value of this variable.
Sure, I was rather asking how make gnatlib (or whatever) is supposed to
be invoked? From gcc/ada, any special needs?
>> I've often had serious trouble when I tried to run make
>> gnatlib/gnatlib-shared in gcc/ada.
>
> Apparently "someone" in the past removed too many things from the Makefile
> which broke partly this support (probably thinking that with libada/Makefile,
> these changes were not needed anymore). We have local changes at AdaCore in the
> Makefile that basically ignores these changes.
It would be good to contribute them, perhaps for close scrutiny by a
build maintainer. If anything goes wrong in libada during a bootstrap,
investigating and manually retrying is currently painful at best.
>> OTOH, it seems you're fine with the general approach of only passing
>> PICFLAG to build gnatlib, not everything else that happens to reside in
>> TARGET_LIBGCC2_CFLAGS?
>
> I think that would be fine, although I'm not 100% sure. I can't remember
> whether we've needed TARGET_LIBGCC2_CFLAGS for other flags on e.g. some
> exotic/non mainstream platform in the past, so can't guarantee that this change
> is a good idea. I'd say worth a try, asa long as we're prepared to have a
> "plan B" in case this change does break some exotic platforms unexpectedly.
I think to correct way to handle this would be in one of the
target-specific sections of gcc/ada/gcc-interface/Makefile.in, adding to
CFLAGS with a comment describing the need.
If we cannot get rid of libada's need for PICFLAG, this blocks the rest
of the toplevel libgcc move, which would be unfortunate.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University