Bugzilla Bug 252664

If $CHOST="i686-pc-linux-gnu" or "i486-pc-linux-gnu" and $(uname -m)="x86_64",
then portage should probably print some warning such as:

WARNING: CHOST does not match uname -m
WARNING: To chroot into a 32-bit environment, use the command "linux32 chroot".
WARNING: See http://www.gentoo.org/proj/en/base/amd64/howtos/chroot.xml for
more information.

(Not sure whether this counts as bug or enhancement.)

Do some applications end up depending on a 64 bit environment, or it the
problem just some failing to build?

What bug do you propose to fix? If it's just user errors, then it probably
won't be implemented...

Created an attachment (id=176539) [details]
Patch which makes portage warn if user didn't use linux32 chroot.

(In reply to comment #1)

User errors.

I hadn't heard of linux32, and didn't know that uname -m is used when building
packages, and was trying to build a 32-bit environment on my fast 64 bit
desktop, to run on a small laptop/"netbook", and didn't think of looking for
documentation before doing it.

I don't know how common/uncommon my situation is, but if it's common enough, a
warning would have saved me a bit of time.

Does a patch against portage 2.1.4.5 improve the chance of it being
implemented? (I don't know python or portage, so the patch could be a bit
strange.)

My opinion is to "read the manual" - If your uname does not say i*86, then of
course your chroot won't be 32bit.

Well, from my experience, there is no problem setting up a 32-bit chroot
without using linux32/i386. Except that once it's set up, if you install
packages beyond the system ones, you'll find a few that produce indecipherable
error messages. A clear warning would've been nice from my point of view.

A note on the patch: if it should be done at all, it should probably check
$ARCH, not $CHOST, so that it catches all cases. I noticed i586-* was missing,
and I know some folks like to be strange with i686-gentoo-linux-gnu and such,
which is valid as far as I know.

Another view: if the build of a package depends on uname's output, then
cross-compiling will certainly fail, so such packages should be fixed anyway.
And if such packages are indeed going to be fixed (if this is going to be
considered a bug in the packages), then there's less of a point in getting a
warning in portage.

Created an attachment (id=176694) [details]
Use ARCH instead of CHOST

(In reply to comment #4 and #5)

I'm not sure what ARCH or CHOST are exactly, but ARCH="x86" seems simpler to
test for than CHOST =~ /i.86-.*/. (I don't know whether python has regular
expressions.)

According to the other view, x11-libs/qt-core-4.4.2 should be fixed to not
depend on uname -m.

P.S. Are all packages supposed to be able to be cross-compiled for an arbitrary
architecture on an arbitrary host? Looking at
http://www.gentoo.org/proj/en/base/embedded/cross-development.xml , I get the
impression that it's actually possible.