Please note I have not really tested this PR. I have tested only that uname -m works on my system. However, I am not sure it works e.g. on i686 and if it even returns some reasonable results inside mock ...

Note the part of the coreutils patch:

  if(strlen(element)==4 && element[0]=='i' && element[2]=='8' && element[3]=='6')
     element[1]='3';

The uname -m return i686, not i386 string.

Not sure, perhaps we could use rpm --eval %_arch instead, or something like that?

Or this:

diff --git a/multilib-library b/multilib-library
index 4971ef3..48b82c9 100644
--- a/multilib-library
+++ b/multilib-library
@@ -47,6 +47,10 @@ fix_arch ()
         ppc64p7)
             eval "$1=ppc64"
             ;;
+        # Related to rhbz#2158752.
+        i686)
+            eval "$1=i386"
+            ;;
     esac
 }

Or this:

Added commit with this idea.

Not sure, perhaps we could use rpm --eval %_arch instead, or something like that?

Hm, calling rpm inside rpm was always frowned upon, although in this case would be probably acceptable.

Nevertheless, the arch can be injected via the %multilib_fix_c_header macro. Or as I propose in the BZ, if the multilib-rpm-config was arch specific, it could even be hardcoded.

Or this:

Added commit with this idea.

Not sure, perhaps we could use rpm --eval %_arch instead, or something like that?

Hm, calling rpm inside rpm was always frowned upon, although in this case would be probably acceptable.

Nevertheless, the arch can be injected via the %multilib_fix_c_header macro. Or as I propose in the BZ, if the multilib-rpm-config was arch specific, it could even be hardcoded.

I.e. this is probably another option to fix this:

$ git diff
diff --git a/macros.ml b/macros.ml
index 4416210..3c5e7a6 100644
--- a/macros.ml
+++ b/macros.ml
@@ -20,7 +20,7 @@
 # Macro multilib_fix_c_header is expected to be called
 # from %install (usually after 'make install' call) like:
 # %multilib_fix_c_header --file %{_includedir}/broken-header.h
-%multilib_fix_c_header @ML_FIX@ --buildroot "$RPM_BUILD_ROOT"
+%multilib_fix_c_header @ML_FIX@ --buildroot "$RPM_BUILD_ROOT" --arch %{_arch}

 # Expands to 'true' if the actual architecture should take care to make
 # the package multilib-clean.  Otherwise expands to 'false'.

I'm looking into this problem in a broader scale. I'm trying to find out how many packages still use the 'uname -i/-p', what problems it causes and which solutions were used by others.

My opinion is that in general, results from 'uname -i/-p/-m' aren't used to differentiate between specific features of the instruction set, but rather to tell what architecture and what bit-size the machine has.

I mean - the 'uname' is used to tell for example whether the machine is ARM or INTEL, and whether is is 32-bit or 64-bit,
but it is not used to examine whether the 32-bit Intel instruction set is i386, i486, i586, i686 or i786.

So I believe that we should always check for the general "i*86", instead of a specific one.

PR looks good to me.