Re: [PATCH] Support multilib-aware target lib flags self-specs overriding

[Alexandre Oliva <oliva@adacore.com>]

On Jun 28, 2022, Alexandre Oliva <oliva@adacore.com> wrote:

> Support multilib-aware target lib flags self-specs overriding

> This patch introduces -fmultiflags, short for multilib TFLAGS, as an
> option that does nothing by default, but that can be added to TFLAGS
> and mapped to useful options by driver self-specs.

> Regstrapped on x86_64-linux-gnu.  Posted mainly FTR, but...  I wouldn't
> mind putting it in, so...  Ok to install?  ;-)

Since this patch didn't seem to gain much traction towards acceptance,
I've been thinking of other ways to accomplish its goal, namely, to
enable target libs to be built with additional flags, like setting
TFLAGS, but enabling different multilibs to be built with different
flags.

The other way that came to mind was to add settings to the multilib
target fragment configurations, say MULTILIB_TFLAGS, to map multilibs to
extra flags to use, and then adjust the target lib multilib flag build
machinery to extract and add these flags when configuring and building
each library.  Yuck.

I'd much rather we could use -fmultiflags, a far more elegant
arrangement IMHO, so...

Ping?  https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597419.html

> for  gcc/ChangeLog

> 	* common.opt (fmultiflags): New.
> 	* doc/invoke.texi: Document it.
> 	* gcc.cc (driver_self_specs): Discard it.
> 	* opts.cc (common_handle_option): Ignore it in the driver.


Since this is kind of a build machinery feature, would anyone mind if I
self-approved this with my build machinery maintainer hat on?

Please raise your objection within one week if you do.

Thanks,

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>