One should depend on
- `stdenv.cc.bintools`: for executables at build time
- `libbfd` or `libiberty`: for those libraries
- `targetPackages.cc.bintools`: for exectuables at *run* time
- `binutils`: only for specifically GNU Binutils's executables, regardless of
the host platform, at run time.
Patch away two things:
- %_includedir, %_oldincludedir, %_mandir, %_infodir macros from
lib/rpm/platform/*/macros to avoid cycles between outputs. Hopefully
anything doesn't really need those.
- Change %__ld, %__nm, %__objcopy, %__objdump in lib/rpm/macros to
refer to the commands in PATH. Should be safe as %__cc for instance is
already like that.
Commit 5dff3c4b68 made rpm use autoreconfHook, so the patch that we
are making to `configure` gets lost when the file is regenerated.
To fix this, just patch the equivalent string in the `configure.ac` file
instead.
Fixes#15287
It turns out that a surprising number of common packages use lua
scripts in RPM files, and not having lua can lead to obscure failures.
The propagatedBuildInputs stuff makes the librpm stuff more useful,
since some of its headers didn't work without extra buildInputs before.
Currently, building RPM with `python = python3` causes this:
checking for a Python interpreter with version >= 2.6... python3
checking for python3... /nix/store/dykqxnrwiz9drlcv2wy8lpvl3xvklx0g-python3-3.4.3/bin/python3
checking for python3 version... 3.4
checking for Python.h... yes
checking for library containing Py_Main... no
configure: error: missing python library
That comes from this snippet in configure.ac:
AC_SEARCH_LIBS([Py_Main],[python${PYTHON_VERSION} python],[
WITH_PYTHON_LIB="$ac_res"
],[AC_MSG_ERROR([missing python library])
])
So it's looking for (e.g) `libpython3.4.so` wheras we have `libpython3.4m.so`.
Patching the configure script to match seems to make that work (although
I don't really understand what the heck is this 'm' business about).
