From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-85732-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by finch.gentoo.org (Postfix) with ESMTPS id A566F138334
for <garchives@archives.gentoo.org>; Wed, 22 Aug 2018 13:21:42 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 7ADE7E0917;
Wed, 22 Aug 2018 13:21:37 +0000 (UTC)
Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 2C11FE07B3
for <gentoo-dev@lists.gentoo.org>; Wed, 22 Aug 2018 13:21:37 +0000 (UTC)
Received: from red.yakaraplc.local (host213-123-185-55.in-addr.btopenworld.com [213.123.185.55])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
(Authenticated sender: chewi)
by smtp.gentoo.org (Postfix) with ESMTPSA id 27235335D1A
for <gentoo-dev@lists.gentoo.org>; Wed, 22 Aug 2018 13:21:34 +0000 (UTC)
Date: Wed, 22 Aug 2018 14:21:18 +0100
From: James Le Cuirot <chewi@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Gentoo i486 support
Message-ID: <20180822142118.01aeec3b@red.yakaraplc.local>
In-Reply-To: <5cc35530-3d96-1a0f-b484-73ea3d58bed5@gentoo.org>
References: <5cc35530-3d96-1a0f-b484-73ea3d58bed5@gentoo.org>
X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-redhat-linux-gnu)
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 7f0e27ac-33c9-484e-beea-9241fd20c352
X-Archives-Hash: 9fcc8a63c7060cd919f73f205d4ec819
On Wed, 22 Aug 2018 07:26:24 -0500
Ben Kohler <bkohler@gentoo.org> wrote:
> For some time now, we've been shipping broken i486 stage3s that do
> not run on pre-i686 hardware [1]. Due to a change in catalyst [2],
> we no longer set CXXFLAGS in the default make.conf, so the x86
> profiles' (imho wrong/broken) defaults [3] kick in.
>=20
> I'd like to get this fixed, and I see 3 possible solutions, listed in=20
> order of my own preference:
>=20
> 1) Adjust x86 profile defaults to drop the problematic -march=3Di686.=20
> This would be more in line with amd64 profiles (et al), which set no=20
> -march value so it can run on any hardware for this arch.
>=20
> 2) Patch catalyst to start setting CXXFLAGS again. Rather than roll=20
> back to exactly CXXFLAGS=3D"${CFLAGS}" again, it's been suggested that
> we start setting COMMON_FLAGS, and CFLAGS=3D"${COMMON_FLAGS}"=20
> CXXFLAGS=3D${COMMON_FLAGS}" etc. I prepared such a patch a while back=20
> [4], which seems to work but may need a bit of updating.
You do get similar issues with other variables. I recently noticed that
CHOST_arm is sometimes used (by LLVM? can't remember=E2=80=A6) instead of j=
ust
CHOST. Because we were only setting CHOST_arm=3D"${CHOST}" in the base
arch/arm profile, it was still carrying the original value of
arm-unknown-linux-gnu regardless of what subprofiles or the user had
set. I've explicitly set it in the subprofiles now but this still isn't
great.
> 3) Drop i486 support. We're only pretending to have support now, we=20
> could officially stop building these broken stages completely.
>=20
> Personally I think #1 is the most technically correct and least
> amount of work. The only result will be slightly less optimized
> builds for people who choose not to customize *FLAGS at all in
> make.conf. But this is correct behavior. What we have now is akin
> to setting -march=3Dcore2 on amd64 stage3 and saying "oops it doesn't
> work on early 64bit AMD cpus, but oh well most people have newer and
> will appreciate the optimization".
I do get nostalgic about this old hardware but I wouldn't expect anyone
to use it now. A year or so ago, I tried to run the latest Linux kernel
in 16MB RAM. I had to use zram just to squeeze out an extra 2MB and
even then, it was at the absolute limit. Bear in mind this was a very
stripped down LEDE installation. 486s can have more RAM but why bother?
The oldest PC I ran Gentoo on in remotely recent times was a Pentium
120 MMX and that was only because the form factor was unusually small.
I would maybe still try it on my Amiga 1200 for laughs but that has the
added novelty factor of not being a PC. On that basis, I would suggest
dropping the stages but that doesn't mean we shouldn't fix things
anyway. Apart from just making it correct, it is possible to install
Gentoo without a stage tarball. I created our bogsucker ppc64le dev box
by cross-compiling @system with the help of my cross-boss tool.
--=20
James Le Cuirot (chewi)
Gentoo Linux Developer