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.
