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
I would like to try to move the optflags definition into the macro file
to make it cleaner and easier to maintain, so to make that easier, I
wanted to start by removing unsupported arches, so there is less code
to move.
If there are no .o/.a files to be distributed, this prevents
check_convert_bitcode from being called without a file argument,
in which case the first flag is going to be treated like the file
name, resulting in something like:
realpath: invalid option -- 'O'
Try 'realpath --help' for more information.
Usage: file [-bcCdEhikLlNnprsSvzZ0] [--apple] [--extension] [--mime-encoding]
[--mime-type] [-e <testname>] [-F <separator>] [-f <namefile>]
[-m <magicfiles>] [-P <parameter=value>] [--exclude-quiet]
<file> ...
file -C [-m <magicfiles>]
file [--help]
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.
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.
Also move this file to kernel-srpm-macros. Note that we need to require
a new kernel-srpm-macros release now, since that's where kmod.attr is
going to end up.
We did this in RHEL-8 [1] so let's not re-introduce the packages in RHEL-9.
Previously, we did that by keeping a downstream-only patch - let's just
have a conditional here, to make the maintenance simpler.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1588575
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
The annobin clang plugin is not actually used anywhere, so we don't
need to have a dependency on it.
This was also creating a circular dependency that was blocking the
latest clang update.
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.
