>> 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
