Re: F37 proposal: RPM Macros for Build Flags (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Tom Stellard:

> On 6/7/22 02:18, Florian Weimer wrote:
>> * Ben Cotton:
>> 
>>> This change will add new macros which will make it easier for packages
>>> to add and remove their own compiler flags.  This strategy is already
>>> used to some extent with feature macros like %{_lto_cflags},
>>> %{_hardening_cflags}, etc, but these new macros will give packagers
>>> even more fine-grained control over the options.
>>>
>>> The proposed macros for adding new flags are:
>>>
>>>      %_pkg_extra_cflags
>>>      %_pkg_extra_cxxflags
>>>      %_pkg_extra_fflags
>>>      %_pkg_extra_ldflags
>> Why isn't it possible to use the environment variables for this?
>> 
>
> Environment variables won't cover all cases.  For example, some packages
> need the flags passed as arguments to make or configure or some other
> build system.

But then you can stick the extra flags into that argument.  I don't see
why this additional hook is needed.

>> This is very misleading because in several cases, clearing the those
>> flags will not affect toolchain behavior because the flag in question
>> merely restates the toolchain default.  In particular, this applies to
>> -fasynchronous-unwind-tables, and it would apply to -march= and -mcpu=
>> if those were in the list.  Likewise to -Wl,-z,relro.
>> Is the goal of this proposal just to achieve a textual flags change
>> (disregarding any change in behavior), or to actually change toolchain

> The goal is to make it easy to remove individual flags so packages can
> get the toolchain behavior they want.

Sorry, this does not answer my question.  What if removing the flag does
not actually change toolchain behavior?

>> If the former, I'm not sure if the actual _flag names are useful.  Maybe
>> we can add an RPM macro to suppress or replace flags based on the flags
>> as they are used instead.  This could also add additional error checking
>> because a name typo in the macro definition will not be immediately
>> obvious.
>> 
>
> Can you give an example of what you mean by this?

You could write:

%build_cxxflags_remove -Wp,-D_GLIBCXX_ASSERTIONS

or some similar construct, and -Wp,-D_GLIBCXX_ASSERTIONS would be
removed from the build flags.

>>> With these new macros, the examples from above could be re-written as:
>>>
>>>      compiler-rt: %global _pkg_extra_cflags -D_DEFAULT_SOURCE
>>>      julia:       %global _flag_glibcxx_assertions %{nil}
>> Do you have some background why -D_DEFAULT_SOURCE is needed?  Why
>> doesn't upstream detect this?
>> 
>
> It was added to workaround this bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25271

This has long since been fixed, so the workaround is no longer needed.

-D_GLIBCXX_ASSERTIONS has zero false positives.  Removing it does not
make the code that triggers the asserts well-defined.  Only the explicit
assertion failure is gone.  So it is probably another example of a flag
where removal does not result in the hoped-for change in toolchain
behavior.

Thanks,
Florian
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux