Use a compiler specs file to avoid issues with escaping and quoting
when a package is built using autotools.
Generate the osCpe string at build time for now, as it's not set
as an env var by rpm yet.
Sync with https://github.com/systemd/package-notes/pull/31
On big endian machines we need to swap the first three fields, which
are binary and thus need to match endianess.
Just use LONG() instead of BYTE sequences.
%_package_note_linker != "bfd" disables note insertion, so that it also works
as another opt-out mechanism. Maybe we can improve support in the future.
From https://bugzilla.redhat.com/show_bug.cgi?id=2043178#c26:
It turns out that gold does something wrong with sections.
When we add the new section, it shifts existing sections (and even gets one section less than before):
│ - Entry point address: 0x500
│ + Entry point address: 0x50
│ Start of program headers: 64 (bytes into file)
│ - Start of section headers: 6328 (bytes into file)
│ + Start of section headers: 8344 (bytes into file)
│ Flags: 0x0
│ Size of this header: 64 (bytes)
│ Size of program headers: 56 (bytes)
│ - Number of program headers: 9
│ + Number of program headers: 8
│ Size of section headers: 64 (bytes)
│ - Number of section headers: 36
│ - Section header string table index: 35
│ + Number of section headers: 38
│ + Section header string table index: 37
There's a bug open to add INSERT AFTER [https://sourceware.org/bugzilla/show_bug.cgi?id=15373],
but it's 8 years old.
Opting out seems to be the best we can do for now.
I also noticed that gold support -dT, only lld doesn't, so the conditional is
adjusted accordingly.
I thought this would allow insertion with ld.gold, but it turns out
that the resulting binary has something wrong with sections. So only the
change to the script is committed, because it makes it much easier to
experiment with various linkers.
READONLY is supported in ld.bfd from binutils >= 2.38, though the
patch was backported in rawhide. It is also unsupported by ld.gold,
so let's make it easy to skip it, since things will also work without
it, just a tiny bit worse.
Thanks to this the file is (in the common case) created in the unpacked
build directory, and not one level up. I.e.
/builddir/build/BUILD/lirc-0.10.0/.package_note-lirc-0.10.0-34.fc36.x86_64
instead of /builddir/build/BUILD/.package_note-lirc-0.10.0-34.fc36.x86_64.ld.
This is nicer esp. for 'fedpkg local' builds, where the dist-git directory is
used as the build dir.
When there are multiple %setup calls, the *last* extracted directory
becomes %{buildsubdir}. This might be confusing, but it shouldn't cause
problems for this use.
Suggested in https://bugzilla.redhat.com/show_bug.cgi?id=2043092#c21.
IIUC, the normal %ifarch syntax cannot be used, because the definition
needs to be inline. The best I could find is %_target_cpu, which seems to be
set to "noarch" for noarch builds.
When subpackages are used, and have different Version fields, we end up with
the version of the last subpackage in %version. But RPM_PACKAGE_VERSION is
set early, and seems to have the right version.
Fixes rhbz#2043143.
The idea was that we can avoid unnecessary work if the macro is called more than
once. But in hindsight this might be risky: let's instead minimize the number of
places where the macros is called, but always overwrite the file so that we
don't end up with a stale version from a previous build.
