Currently, when the clang toolchain is used, we use the
brp-llvm-compile-lto-to-elf script to post-process any shipped
object files or static libraries to convert the LLVM bitcode they
contain into ELF object code.
With LLVM 18, Clang has introduced support for fat LTO objects
(https://llvm.org/docs/FatLTO.html), which work essentially the
same way as with GCC: If `-ffat-lto-objects` is passed, then the
objects will contain both the ELF code, as well as the LLVM
bitcode in a special section.
This redhat-rpm-config change enables the use of fat LTO and
drops the brp-llvm-compile-lto-to-elf script. Instead, the
brp-strip-lto script used by GCC also strips the LLVM section
name now.
This is part of https://fedoraproject.org/wiki/Changes/LLVM-18.
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/277
reverted the requirement for rust-srpm-macros to define %build_rustflags.
Since RHEL's rust package will provide that as a subpackage with its
own versioning scheme rather than rust-packaging's, the version constraint
needs to be dropped.
No conflict because except for %global build_type_safety 0,
the package is still compatibility with GCC 13 (but does not
enforce the type safety levels anymore).
Now that rust-packaging absorbed rust-srpm-macros in Fedora, RHEL rust
will need to provide an srpm-macros subpackage so that no part of
rust-packaging will be pulled into RHEL 10. This will then allow
rust-packaging (minus macros.rust-srpm) to exist in EPEL.
While these macros were previously shipped as a subpackage of
python-rpmautospec, they do not depend on the Python module, and the
rest of that package includes dependencies not wanted in RHEL/ELN (such
as koji).
The package redefines %optflags on i686 and s390x, so the
%__build_for_lang_* macros are no longer expanded, triggering
a warning from RPM (“%__build_for_lang_any defined but not
used within scope”). Clang warns about -Wno-complain-wrong-lang
with -Wall, so the warning option is suppressed for
"%toolchain" != "gcc".
Reported-by: Tulio Magno Quites Machado Filho <tuliom@ascii.art.br>
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/