1 |
On Wed, 22 Aug 2018 07:26:24 -0500 |
2 |
Ben Kohler <bkohler@g.o> wrote: |
3 |
|
4 |
> For some time now, we've been shipping broken i486 stage3s that do |
5 |
> not run on pre-i686 hardware [1]. Due to a change in catalyst [2], |
6 |
> we no longer set CXXFLAGS in the default make.conf, so the x86 |
7 |
> profiles' (imho wrong/broken) defaults [3] kick in. |
8 |
> |
9 |
> I'd like to get this fixed, and I see 3 possible solutions, listed in |
10 |
> order of my own preference: |
11 |
> |
12 |
> 1) Adjust x86 profile defaults to drop the problematic -march=i686. |
13 |
> This would be more in line with amd64 profiles (et al), which set no |
14 |
> -march value so it can run on any hardware for this arch. |
15 |
> |
16 |
> 2) Patch catalyst to start setting CXXFLAGS again. Rather than roll |
17 |
> back to exactly CXXFLAGS="${CFLAGS}" again, it's been suggested that |
18 |
> we start setting COMMON_FLAGS, and CFLAGS="${COMMON_FLAGS}" |
19 |
> CXXFLAGS=${COMMON_FLAGS}" etc. I prepared such a patch a while back |
20 |
> [4], which seems to work but may need a bit of updating. |
21 |
|
22 |
You do get similar issues with other variables. I recently noticed that |
23 |
CHOST_arm is sometimes used (by LLVM? can't remember…) instead of just |
24 |
CHOST. Because we were only setting CHOST_arm="${CHOST}" in the base |
25 |
arch/arm profile, it was still carrying the original value of |
26 |
arm-unknown-linux-gnu regardless of what subprofiles or the user had |
27 |
set. I've explicitly set it in the subprofiles now but this still isn't |
28 |
great. |
29 |
|
30 |
> 3) Drop i486 support. We're only pretending to have support now, we |
31 |
> could officially stop building these broken stages completely. |
32 |
> |
33 |
> Personally I think #1 is the most technically correct and least |
34 |
> amount of work. The only result will be slightly less optimized |
35 |
> builds for people who choose not to customize *FLAGS at all in |
36 |
> make.conf. But this is correct behavior. What we have now is akin |
37 |
> to setting -march=core2 on amd64 stage3 and saying "oops it doesn't |
38 |
> work on early 64bit AMD cpus, but oh well most people have newer and |
39 |
> will appreciate the optimization". |
40 |
|
41 |
I do get nostalgic about this old hardware but I wouldn't expect anyone |
42 |
to use it now. A year or so ago, I tried to run the latest Linux kernel |
43 |
in 16MB RAM. I had to use zram just to squeeze out an extra 2MB and |
44 |
even then, it was at the absolute limit. Bear in mind this was a very |
45 |
stripped down LEDE installation. 486s can have more RAM but why bother? |
46 |
The oldest PC I ran Gentoo on in remotely recent times was a Pentium |
47 |
120 MMX and that was only because the form factor was unusually small. |
48 |
I would maybe still try it on my Amiga 1200 for laughs but that has the |
49 |
added novelty factor of not being a PC. On that basis, I would suggest |
50 |
dropping the stages but that doesn't mean we shouldn't fix things |
51 |
anyway. Apart from just making it correct, it is possible to install |
52 |
Gentoo without a stage tarball. I created our bogsucker ppc64le dev box |
53 |
by cross-compiling @system with the help of my cross-boss tool. |
54 |
|
55 |
-- |
56 |
James Le Cuirot (chewi) |
57 |
Gentoo Linux Developer |