This problem very likely occurs in DNF too. I am cloning it solely to document the use cases for bug 1163028.
The resolution of this bug depends on how we decide to document behaviour of --installroot.


+++ This bug was initially created as a clone of Bug #1178580 +++

Description of problem:
Running on an x86_64 Fedora 20 host, I cannot use mock to rebuild RPMs
for the target 'fedora-20-i386' or 'fedora-21-i386'. In both cases
attempts to build the RPM will fail at ./configure time because the C
compiler cannot be run. The reason it can't be run is that despite this
theoretically being a 32-bit buildroot, vast swatches of x86_64 RPMs have
been installed and vast swatches of i686 RPMs (such as libc) have *not*
been installed.

This is a fairly severe issue because it prevents rebuilding i686
packages on an x86_64 host if you have local versions of a dual
architecture package installed and now need to update it for some
reason. Without the ability to rebuild a 32-bit version, you're
screwed (as I am now).

Version-Release number of selected component (if applicable):
mock-1.2.3-1.fc20.noarch
yum-3.4.3-152.fc20.noarch

This also happens on several prior releases of mock, so it may be a
behavior change in yum.

How reproducible:

Completely.

Steps to Reproduce:

1. Get a source RPM. Freetype will do.
2. mock -r fedora-20-i386 --scrub all
3. setarch i386 mock --verbose -r fedora-20-i386 freetype-2.5.0-7.fc20.src.rpmo

setarch isn't supposed to be necessary but I've provided it as an
extra-large hammer.

Actual results:

Build run eventually fails with:

DEBUG: configure: WARNING: unrecognized options: --disable-dependency-tracking
DEBUG: checking build system type... x86_64-redhat-linux-gnu
DEBUG: checking host system type... x86_64-redhat-linux-gnu
DEBUG: checking for x86_64-redhat-linux-gnu-gcc... no
DEBUG: checking for gcc... gcc
DEBUG: checking whether the C compiler works... no
DEBUG: configure: error: in `/builddir/build/BUILD/freetype-2.5.0/builds/unix':
DEBUG: configure: error: C compiler cannot create executables
DEBUG: See `config.log' for more details
DEBUG: make: *** [setup] Error 77

Inspection of the install logs will reveal that, for example, there
are no 32-bit libraries that freetype depends on installed; the versions
(and -devel versions) are x86_64 versions.

Expected results:

Build completes, produces 32-bit binaries.

Additional info:

I will attach the full output of a mock run and the config.log output.


--- Additional comment from Chris Siebenmann on 2015-01-08 08:29:16 EST ---

My current yum version is indeed yum-3.4.3-152.fc20.noarch. 'rpm -V yum'
says it's unmodified except /etc/yum.conf, which I modified to keep more
kernels ('installonly_limit=...').

It does appear to be yum. 'setarch i386 yum ...' tries to install 64-bit
packages. The very first package it tries to install is:

    Resolving Dependencies
    --> Running transaction check
    ---> Package bash.x86_64 0:4.2.53-1.fc20 will be installed

So from the moment it starts picking packages it's going bad.
After the first try (with the command line as-is) did this, I
retried with '--disablerepo=* --enablerepo fedora --enablerepo
updates' and it did the same thing.

I can't see anything in the yum output up to that point that's
useful. setarch itself works; 'setarch i386 uname -m' shows the
expected i686 and 'setarch i386 python' followed by importing the
os module and looking at 'os.uname()[4]' also show i686.

Oh! I found it!

rpmUtils.arch.getCanonArch() looks at /etc/rpm/platform first unless
called with 'skipRpmPlatform=True', which arch.py doesn't seem to do.
I have an /etc/rpm/platform with 'x86_64-redhat-linux' (and I don't know
where it comes from, it's been there since 2006). With this removed,
everything seems to work fine (eg the yum command above works).

Is yum checking /etc/rpm/platform a recent change? (Either by adding that
code or by no longer calling getCanonArch() with skipRpmPlatform=True.)

This definitely didn't used to happen in Fedora 20 (and in earlier
Fedora versions this machine has run); I've built and rebuilt 32-bit
RPMs on my machine before, although probably not in the last few months.

--- Additional comment from Miroslav Suchý on 2015-01-08 09:14:24 EST ---

> Oh! I found it!

Perfect!

Does 
  rpm -qf /etc/rpm/platform
say something?

So it is yum bug. Reassigning. It is weird that this behaviour happen now to you.
The code is in yum since:
  Tue Feb 17 05:22:35 2004

IMO correct solution should be to not read /etc/rpm/platform, but to read ${installroot}/etc/rpm/platform (if exists).
However since yum is in maintance mode now, feel free to close it as DEFERRED.

I done 'git grep' in dnf.git and it appear the code is not there. So DNF should be safe.

--- Additional comment from Chris Siebenmann on 2015-01-08 10:43:44 EST ---

'rpm -qf /etc/rpm/platform' says that it's not owned by a package. This
machine was initially installed in 2006 and has been upgraded from
Fedora version to Fedora version ever since; /etc/rpm/platform appears
to have been written during that initial installation (it's got about
the right timestamp for it) and then never touched afterwards.

(/etc/rpm/platform appears to be a 2002-era feature that was designed
to get rpm out of the business of parsing uname(2) to determine the
architecture. More modern Fedora installs, such as a machine initially
installed in 2011 and upgraded from version to version since then, do
not have an /etc/rpm/platform. I suspect that at one point the installer
created it because rpm wanted it and then that feature was backed out of
rpm and thus the installer.)

As a result, I suspect that this is not an important bug (especially
with yum in maintenance mode).

As for timing of when this broke for me and versions of packages, it
looks like I probably last rebuilt a i686 package with mock in March 2014,
and at the time I probably had yum-3.4.3-137.fc20 and mock-1.1.36-1.fc20
(based on /var/log/yum.log*'s logging of what was updated when). I can't
see anything obvious in 'rpm -q --changelog' for mock or yum since then.