with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
Without that, RPM is unable to handle packages that require `rpmlib(FileCaps)`;
example error message trying to install Fedora 36 shadow-utils:
`rpmlib(FileCaps) <= 4.6.1-1 is needed by shadow-utils`.
This contribution uses an upstream fixrpm-software-management/rpm#1775
To limit the chances of breaking other architectures or systems the
patch is only used when we target darwin aarch64.
The Darwin build has been broken with a missing header file "omp.h";
llvmPackages.openmp provides it.
Including this library is only necessary when clang is used.
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).
