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_ldflagsWhy 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.
The proposed new macros to represent existing flags are: %_flag_fstack_protector_strong -fstack-protector-strong %_flag_z_now -Wl,-z,now %_flag_z_defs -Wl,-z,defs %_flag_flto_auto -flto=auto %_flag_ffat_lto_objects -ffat-lto-objects %_flag_o -O2 %_flag_f_exceptions -fexceptions %_flag_g -g %_flag_grecord_gcc_switches -grecord-gcc-switches %_flag_pipe -pipe %_flag_wall -Wall %_flag_werror_format_security -Werror=format-security %_flag_fortify_source -Wp,-D_FORTIFY_SOURCE=2 %_flag_glibcxx_assertions -Wp,-D_GLIBCXX_ASSERTIONS %_flag_asynchronous_unwind_tables -fasynchronous-unwind-tables %_flag_fstack_clash_protection -fstack-clash-protection %_flag_fcf_protection -fcf-protection %_flag_mbranch_protection_standard -mbranch-protection=standardThis 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 behavior?
The goal is to make it easy to remove individual flags so packages can get the toolchain behavior they want.
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?
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 -Tom
Thanks, Florian _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
