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.
number of CPUs will never be set to less than 1
this now outputs build flag overrides to be used with %make_build etc.
add documentation
Signed-off-by: Michel Alexandre Salim <salimma@fedoraproject.org>
A number of cases have cropped up where things like documentation
builds fail with out of tree builds because tools like Doxygen like
encoding the build path into the documentation metadata.
This causes failures in Koji and other places where noarch documentation
subpackages from archful packages fail because they fail the comparison
check due to this.
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.
If the file we are trying to mangle a shebang in has
0 lines (as reported by `wc`) `read` command fails
to read the first line and the script fails silently.
Text files without newlines should not be executable as there
is no way for them to contain a shebang.
Avoid using the full path and instead rely on PATH being correctly set
up to find the executable.
This fixes byte compilation for python2.7 when doing flatpak module
builds where python2.7 can be in either /usr/bin or /app/bin, depending
on how it's compiled.
