Re: [lfs-dev] Future of i686 builds (in gcc, et al.)

[Paul Rogers]

>> So, as I now work through LFS-8.1, and read the options in building
>> gcc and other places, it seems to me kernel 4.x-based software has
>> just gotten too "heavy" for i686 to be a reasonable build.

> Could you please elaborate and give some pointers, why you think this?
> 
> Paul

It's largely a matter of personal opinion, but in mine, 1) software 
contemporaneous with the hardware has much to recommend it.  It generally 
works!  For example, in the (B)LFS-7,10 system I mentioned, the latest and last 
Intel driver for X doesn't work on an i810E chipset, while the earlier 
(B)LFS-7.7 build does.  Back in the day, I was introduced to the term "creeping 
featuritis", and have often seen it since.  (Firefox, anyone?)  2) As shown by 
not getting PTI in the 4.9.75 kernel for i686, kernel "improvements" aren't 
necessarily made in all cases.  One should ask what is fixed, in what use 
cases, for the hardware system specifically in question.  You'll notice that I 
do patch up beyong the kernel versions originally built in my LFS builds, but 
only to a certain point that is a matter of my judgement.  3) If one were to 
ascribe i686 compatibility, that should include at least Pentium IIIs, if not 
Pentium-Pros, and I notice performance degradation on my 1GHz "Coppermine".  My 
"Coppermine" maxes-out at 512MB of SDRAM.  LFS-7.2 & 7.7 systems run fine on 
it, but I _am_ careful about letting them out on the Internet and only behind 
an external firewall besides their own.  Not very much further than the 
Pentium-4 "Northwood" data was shown on, x86-64 EMT began to be introduced into 
the P4 family where it was likely used.

It is a matter of how much time and effort one is willing to expend.  (I 
remmeber 8-12 *hour* Firefox compilations on a Pentium-MMX 233!)  Is it the 
book's place to raise the question, or should one expect the LFS user to 
already understand the implications?  I don't think it would be inappropriate 
for the book, from this point, to only build 64-bit systems, possibly 
suggesting if an i686 system is desired an earlier book would be more 
appropriate.  My 7.2 & 7.7 systems are still active.

> ---
> A second version of the i686 meltdown patches were posted this week.
> https://lkml.org/lkml/2018/3/5/173 - I guess in a few weeks a later
> version will get into Linus's tree and then into the maintained
kernels.
> 
> ĸen

Yes, I saw that yesterday--along with Linus' comment that sane people should 
only be using x86-64 kernels.  Won't work on my "Coppermine", and I need to 
keep that running because some of its other services won't run on anything 
newer.  I think I'll grab this, AND wait for the official patches.

> ---
>> The i686 version runs fine..
> 
> What does that means? Nothing explodes?
>

Indeed, because the "Conroe" only has 4GB of RAM, and the shorter i686 
instructions can address virtually all of it.  It _was_ built on an i7, and 
claims to be i686 compatible, so it did need testing to see if it did explode 
on a real i686.  And yes, I do have a "Tualatin" in service (had two but one 
got unreliable).

> It's well known that people use faster hardware to build for 
> machines that compile slower, yet can run the same 
> applications just as fast as the machines that complied it.
> 
> Berzerkula

One might quibble about "just as fast"--only perceptably so.  But the question 
should be about recommending a course of action that would require 
cross-compiling (which I did) on a significantly faster machine, with possibly 
different architecture, and requiring one to "persuade" gmp to behave as 
desired.

> ---
> Maybe you don't know about Rob Landley's mkroot project (its 
> only url for the moment:https://github.com/landley/mkroot) but
> essentially, the project build gcc toolchain for a number of
> architecture including i486
>
> Alain

I've built LFS systems back to 2.1, and had that running on a real 486 DX-33 as 
late as 2016.  (It's main issue was having a Dallas Semiconductor battery/clock 
chip, and I was running out of working chips!)


-- 
Paul Rogers
paulgrog...@fastmail.fm
Rogers' Second Law: "Everything you do communicates."
(I do not personally endorse any additions after this line. TANSTAAFL :-)
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Future of i686 builds (in gcc, et al.)

[rslovers]

On Thu, Mar 08, 2018 at 10:31:40PM +0100, Thomas Trepl wrote:
> Would you mind to try https://io.ax.lt/LFS/lfs/book/index.html ?

Thanks for the link and effort, I had a brief look and I will try
it the next time I build my system, glad to know it exists.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Future of i686 builds (in gcc, et al.)

[Thomas Trepl]

Am Donnerstag, den 08.03.2018, 17:27 +0300 schrieb rslov...@yandex.com:
> I don't have any old hardware but I always build entire i686
> userland, my sole
> motivation is to use wine to run old games, but it's a strong enough
> one, and
> I sincerely think I would be doing this forever...
> 
> Never tried the multiarch way, it just seems too messy for me.

Would you mind to try https://io.ax.lt/LFS/lfs/book/index.html ?

--
Thomas
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Future of i686 builds (in gcc, et al.)

[Alain Toussaint]

> I call that a "heavy lift".  So my question morphed into: when does i686 
> hardware just lack the
> horsepower to "run" modern, i.e. kernel-3.x or kernel-4.x, LFS systems?

Maybe you don't know about Rob Landley's mkroot project (its only url for the 
moment:https://github.
com/landley/mkroot) but essentially, the project build gcc toolchain for a 
number of architecture
including i486 and then, build dropbear, a musl dynamic linked libc and a 4.14 
kernel able to boot
on said 486, admittedly, under qemu and with 256MB of ram (real hardware didn't 
have that much at
the time) and I just pinged them an email to their list so that some work goes 
intobuilding an LFS
system under the that toolchain so that old and random hardware can use LFS.

Alain

mkroot: gcc 6.3, musl-libc git release, toybox and busybox, kernel 4.14.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Future of i686 builds (in gcc, et al.)

[rslovers]

I don't have any old hardware but I always build entire i686 userland, my sole
motivation is to use wine to run old games, but it's a strong enough one, and
I sincerely think I would be doing this forever...

Never tried the multiarch way, it just seems too messy for me.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Future of i686 builds (in gcc, et al.)

[Ken Moffat]

On Thu, Mar 08, 2018 at 07:50:48AM +0100, Paul Menzel wrote:
> 
> > p.s. I still hope to get Meltdown/Spectre patches for linux-4.1.x
> > i686 builds.
> 
> As Linux 4.1 is a longterm series, you should get these patches.
> Though, I’d just update to the latest Linux kernel release, also for
> finding regressions, if you are interested in i686 working well.
> 

A second version of the i686 meltdown patches were posted this week.
https://lkml.org/lkml/2018/3/5/173 - I guess in a few weeks a later
version will get into Linus's tree and then into the maintained
kernels.

For Spectre, I think the amelioration is already in the stable
trees, certainly it's in 4.9 and I think it will work on i686, with
gcc-7.3 for the full mitigation.  But I agree meltdown is the bigger
problem.

But no, building on most i686 machines became painful years ago
(for typical home users, the memory was small and, by current
standards, slow).  Today, x86_64 with less than 8GB can be painful
when building some packages.

ĸen
-- 
Truth, in front of her huge walk-in wardrobe, selected black leather
boots with stiletto heels for such a barefaced truth.
 - Unseen Academicals
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Future of i686 builds (in gcc, et al.)

[William Harrington]

On Wed, 07 Mar 2018 11:57:20 -0800
Paul Rogers  wrote:

> The i686 version runs fine..

What does that means? Nothing explodes?

>I wanted to check that it runs as advertized in a "real" i686 with no extra 
>instructions on the side.

What does that mean?

It's well known that people use faster hardware to build for machines that 
compile slower, yet can run the same applications just as fast as the machines 
that complied it. Frankly, I'd suggest you retire your P3 coppermine and move 
to tualatin. That's where the gold is in P3 land. Never had issues when I was 
using dual P3 tualatins. Don't use the hardware anymore. If you want it, I'll 
send it to you. I have multiple motherboards and they have onboard SCSI which 
was nice at the time, still is nice.

Sincerely,

Berzerkula 
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Future of i686 builds (in gcc, et al.)

[Paul Menzel]

Dear Paul,


Am Mittwoch, den 07.03.2018, 11:57 -0800 schrieb Paul Rogers:

[…]

> So, as I now work through LFS-8.1, and read the options in building
> gcc and other places, it seems to me kernel 4.x-based software has
> just gotten too "heavy" for i686 to be a reasonable build.

Could you please elaborate and give some pointers, why you think this?

[…]

> p.s. I still hope to get Meltdown/Spectre patches for linux-4.1.x
> i686 builds.

As Linux 4.1 is a longterm series, you should get these patches.
Though, I’d just update to the latest Linux kernel release, also for
finding regressions, if you are interested in i686 working well.


Kind regards,

Paul


[1] https://www.kernel.org/
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page