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 attachment 176539 [details, diff] 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 attachment 176694 [details, diff] 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.
(In reply to comment #5) > 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. Right. Also, default/linux/amd64/dev/32bit-userland/make.defaults contains CHOST="i686-pc-linux-gnu", so the warning just isn't valid in plenty of cases.
Now I see that you changed it to use ARCH which is a little more valid. However, I'm still not sure about the warning. Though 32bit-userland profile has ARCH=amd64, wouldn't ARCH=x86 also be valid?
Back when this was reported, there were no 32-bit amd64 profiles yet. Now that there are, yes, this warning really shouldn't go in portage anymore. Any packages that fail to build should be fixed, and any fixes for amd64 32bit-userland will also fix 64-bit kernel x86 systems.
