RFC: [build, ada] Centralize PICFLAG configuration

As has been mentioned before, one impediment to complete the toplevel
libgcc move is libada's use of TARGET_LIBGCC2_CFLAGS.  AFAICS, it is
primarily used for gnatlib-*shared targets, so I assume that this was
done mostly (exclusively?) to get the flags necessary for PIC code
generation.  Since those flags aren't used for the static libgnat.a, it
were strange that the non-PIC flags were actually required, given that
all gnat.dg and ada/acats testing is only done with the static library.

If this is true, then we need two things:

* Change gcc-interface/Makefile.in and libada/Makefile.in to use PICFLAG
  instead of TARGET_LIBGCC2_CFLAGS.  This is what the patch below does.

* Centralize the determination of PICFLAG.  Currently, three libraries
  inside the gcc tree are built PIC without libtool: libgcc, libiberty,
  and libgnat/libgnarl.

  libiberty/configure.ac has a hardcoded list of PICFLAG that could be
  moved to a toplevel 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.

I've used the patch below as a proof-of-concept to complete the toplevel
libgcc move.  Together with companion patches to actually move all the
LIBGCC2* and LIB2* variables and corresponding files to toplevel libgcc,
I've sucessfully bootstrapped on i386-pc-solaris2.11.

Comments, suggestions?

	Rainer


2011-07-31  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	gcc/ada:
	* gcc-interface/Makefile.in (GNATLIBCFLAGS_FOR_C): Replace
	TARGET_LIBGCC2_CFLAGS by PICFLAG.
	(gnatlib-shared-default, gnatlib-shared-dual-win32,
	gnatlib-shared-win32, gnatlib-shared-darwin, gnatlib-shared,
	gnatlib-sjlj, gnatlib-zcx): Likewise.

	libada:
	* configure.ac (PICFLAG): Set.
	Substitute.
	* configure: Regenerate.
	* Makefile.in (TARGET_LIBGCC2_CFLAGS): Replace by PICFLAG.
	(GNATLIBCFLAGS_FOR_C): Replace TARGET_LIBGCC2_CFLAGS by PICFLAG.
	(LIBADA_FLAGS_TO_PASS): Likewise.
	Don't include $(GCC_DIR)/libgcc.mvars.

On 08/10/2011 01:42 PM, Rainer Orth wrote:
> * Centralize the determination of PICFLAG.  Currently, three libraries
>    inside the gcc tree are built PIC without libtool: libgcc, libiberty,
>    and libgnat/libgnarl.
>
>    libiberty/configure.ac has a hardcoded list of PICFLAG that could be
>    moved to a toplevel config/picflag.m4.

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).

Paolo

> 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

Arnaud Charlet <charlet@adacore.com> writes:

>> 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.

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?

> 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?
I've often had serious trouble when I tried to run make
gnatlib/gnatlib-shared in gcc/ada.

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?

Thanks.
	Rainer

> 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).

> > 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.

> 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.

> 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.

Arno

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

On 08/16/2011 09:52 AM, Arnaud Charlet wrote:
>
>> >  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.

Please post them.

Paolo

On 08/16/2011 09:44 AM, Rainer Orth wrote:
>> >  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?
> I've often had serious trouble when I tried to run make
> gnatlib/gnatlib-shared in gcc/ada.

No, you need GCC_PICFLAG_FOR_TARGET that dispatches on $target rather 
than $host.
But it is still easy.

> 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?

We can always try, and later introduce TARGET_GNATLIB_CFLAGS if it turns 
out to be a problem.

Paolo

> Sure, I was rather asking how make gnatlib (or whatever) is supposed to
> be invoked?  From gcc/ada, any special needs?

From <obj dir>/gcc typically.

> It would be good to contribute them, perhaps for close scrutiny by a

well, it's not a matter of contributing: it's more a matter of undoing what
was removed, but Makefiles are tricky, and it's never been a priority.

> If we cannot get rid of libada's need for PICFLAG, this blocks the rest
> of the toplevel libgcc move, which would be unfortunate.

Well, PICFLAG certainly is needed, but you do seem to have a plan for that.
Let's assume that's all we need for now.

Arno