On Jun 28, 2022, Alexandre Oliva <ol...@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>
