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.
%_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.
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.
