public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: James Le Cuirot <chewi@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Gentoo i486 support
Date: Wed, 22 Aug 2018 14:21:18 +0100	[thread overview]
Message-ID: <20180822142118.01aeec3b@red.yakaraplc.local> (raw)
In-Reply-To: <5cc35530-3d96-1a0f-b484-73ea3d58bed5@gentoo.org>

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.
> 
> I'd like to get this fixed, and I see 3 possible solutions, listed in 
> order of my own preference:
> 
> 1) Adjust x86 profile defaults to drop the problematic -march=i686. 
> This would be more in line with amd64 profiles (et al), which set no 
> -march value so it can run on any hardware for this arch.
> 
> 2) Patch catalyst to start setting CXXFLAGS again.  Rather than roll 
> back to exactly CXXFLAGS="${CFLAGS}" again, it's been suggested that
> we start setting COMMON_FLAGS, and CFLAGS="${COMMON_FLAGS}" 
> CXXFLAGS=${COMMON_FLAGS}" etc.  I prepared such a patch a while back 
> [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…) instead of just
CHOST. Because we were only setting CHOST_arm="${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 
> could officially stop building these broken stages completely.
> 
> 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=core2 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.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


  parent reply	other threads:[~2018-08-22 13:21 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-22 12:26 [gentoo-dev] Gentoo i486 support Ben Kohler
2018-08-22 13:08 ` Rich Freeman
2018-08-22 13:23   ` Mart Raudsepp
2018-08-22 14:22   ` Peter Stuge
2018-08-22 20:27   ` R0b0t1
2018-08-22 20:39     ` Rich Freeman
2018-08-25 11:07   ` Andrew Savchenko
2018-08-22 13:21 ` James Le Cuirot [this message]
2018-08-22 14:30 ` Mike Gilbert
2018-08-22 15:27   ` Thomas Deutschmann
2018-08-22 19:20 ` Matt Turner
2018-08-22 19:27   ` M. J. Everitt
2018-08-22 20:19 ` Richard Yao
2018-08-24 13:19 ` Kent Fredric
2018-08-24 13:57   ` Mike Gilbert
2018-08-24 14:13     ` Rich Freeman
2018-08-24 14:40       ` Kent Fredric

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180822142118.01aeec3b@red.yakaraplc.local \
    --to=chewi@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox