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
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.
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.
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.
There appears to be new rpm behavior which adds
Requires(interp): /bin/sh
to this package, so we need to account for this in requires.txt.
We already have /usr/bin/sh in requires.txt, so this is not a
new dependency.
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.)
