The two intended uses cases for the _pkg_extra_* macros were to
make it easier for packagers to add new compile flags for use
with their package and also to make it easier to do distro wide
experiments with new flags.
However, it was pointed out on the mailing list[1] that you
can't satisfy both of these uses cases at the same time with
just one set of macros. For example, if a packager uses
_pkg_extra_* macros to add flags specific to their own
package, then someone using _pkg_extra_* macros to
apply a new flag distro wide would override the package
specific flag.
I feel like the distro-wide use case is much more important,
so rather than create two sets of new flags, one for each use
case, I think it's best to rename the _pkg_extra_* macros
to _distro_extra_* and document that they are only meant
to be used for adding distro-wide flags and packagers should
not use this macro.
[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TOG5RHWPS3VYMM52HFGZOUJVRCGZ7VXB/
The double undefine was unnecessary and exposed a bug in ccache. Club
the undefine and define into a single -Wp instead, which works for all
redefinitions of _FORTIFY_SOURCE.
RHEL does not intend to enable frame pointers at this time, and any
change will be done so based on a variety of inputs including the data
from Fedora. Disable them for ELN to set proper expectations.
Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
Make the _FORTIFY_SOURCE flags configurable so that the command line is
not cluttered with _FORTIFY_SOURCE definitions and undefines. Introduce
a %_fortify_level variable that a package may override by either
undefining or defining to a specific value.
Also bump the default value to 3, to implement the systemwide proposal
for Fedora 38:
https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
If `%_include_frame_pointers` is defined, add `-fno-omit-frame-pointer`
and `-mno-omit-leaf-frame-pointer` to the compiler flags to ensure frame
pointers are always included.
This is in preparation for
https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer
This requires the build system support VALAFLAGS. At least Meson and
Automake do.
Using -g is desired because it allows us to see Vala source files and
line numbers in backtraces when possible, falling back to generated C
code otherwise. Line numbers for generated C are almost always less
useful when debugging crashes.
From https://bugzilla.redhat.com/2083296:
> The issue is that some packages break up the flags at spaces,
> in order to look for specific flags or to add flags of their own.
> The z3 package, for example, has some python code that does this:
>
> def exec_cmd(cmd):
> if isinstance(cmd, str):
> cmd = cmd.split(' ')
> ...
>
> The result is one of the commands in the list consists of a single tab character.
> When that is passed to the compiler, the compiler does not like it at all.
Packages which do not have %%build section but do also
compile and link test programs in %%check would fail because
no package note would have been generated.
We would try to regenerate the file whenever set_build_flags was used.
For packages which call %configure multiple times this would mean a
few times during build, and also in the build and check
preambles. Let's just simplify this and call it only in the build preamble.
https://src.fedoraproject.org/rpms/package-notes/pull-request/1
changes %_generate_package_note_file to be unconditional. This means we'll
always rewrite the file and will not use a stale version. (But the two
fixes are independent, even though they make the most sense together.)
This is already the default for ld.bfd, so this is effectively a no-op
for most packages. However, lld defaults different build-id algorithm
that the RPM build process does not support, so it needs this flag.
This flag can be overriden by setting the %_build_id_flags macro,
which packages could do if they wanted to use a more secure build-id
algorithm.
The brp-llvm-compile-lto-elf script uses PCRE in grep to match
for the -flto flag in bitcode object dumps, using negative
lookahead to exclude the case where -fno-lto is specified after.
When lines in the bitcode dump exceed the length that PCRE can
match against, grep will error out causing brp-llvm-compile-lto-elf
to fail.
This script implements an equivalent regex match in python to avoid
the limit in PCRE grep.
Resolves: rhbz#2017193
RPM requires macros to be at least 3 characters, so we need to
rename the cc macro anyway and using the build_ prefix is consistent
with other macros like build_cflags.
This allows us to maintain our own BuildRoot Policy scripts in an easier way.
This change needs to be coordinated with the addition of the files to python-srpm-macros.
redhat-rpm-config requires python-srpm-macros, so no significant change is expected for the packagers.
This also moves the Python BRPs to the end of the list which should be fine.
The script was dropped in rpm 4.17.0 beta1, so we can't very well
try to use it on builds. For now I'm intentionally dropping just the
macro definition: in case the Python community wants to bring it
back, all they need to do is revive the script and add the macro
definition for it.
On armv7hl, enabling annobin can in some cases lead to corrupt unwind
information in generated object files:
https://bugzilla.redhat.com/show_bug.cgi?id=1951492
The root-cause of this is still unclear and until this is sorted out,
it is best to disable annobin on the architecture.
