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
- From: Arnaud Charlet <charlet at adacore dot com>
- To: Paolo Bonzini <bonzini at gnu dot org>
- Cc: Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>, gcc-patches at gcc dot gnu dot org, Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>, "Joseph S. Myers" <joseph at codesourcery dot com>, Arnaud Charlet <charlet at adacore dot com>
- Date: Tue, 16 Aug 2011 14:44:45 +0200
- Subject: Re: RFC: [build, ada] Centralize PICFLAG configuration
- References: <yddpqkdmr1o.fsf@manam.CeBiTec.Uni-Bielefeld.DE> <4E42AAB2.9010905@gnu.org>
> That's the simplest alternative. It would need however a pass through the
> config/ directory for targets that are never used as hosts for GCC (and
> thus libiberty).
>
> Alternatively, the libtool code could be extracted to config/picflag.m4.
>
>> Alternatively, one could think about using libtool --config | grep
>> pic_flag to determine the flag without actually using libtool.
>>
>> Last, one completely could go for libtool, but I very much doubt such
>> a suggestion would get much traction.
>>
>> My current plan is to merge the PICFLAG information from libiberty and
>> libgcc into picflag.m4 and use that.
>
> Yes, that needs to be done of course. I'm not sure if we still support
> gnatlib_and_tools to build libada/gnattools. If so, we would need the
> PICFLAG to be available somehow in the gcc Makefile (perhaps by providing
> GCC_TARGET_PICFLAG in addition to GCC_PICFLAG in picflag.m4).
Yes, we still need that. Building separately gnatlib/gnatools is still in
production at AdaCore, because the GCC multilib mechanism isn't quite
suitable/would need to be merged with GNAT's need of multiple run-times.
So passing PICFLAG down to the gcc/ada/gcc-interface Makefile and not
just via libada/Makefile is indeed important.
Arno