> Paul, without any more details, that isn't much to go on (you seem "Ask, and thou shalt receive." Well, I don't have the gcc-build directory around any longer, as instructed. As implied, I was/am unsure what's relevant. Now I'm thinking the fault was assuming the cross- compile triplet i686-pc-linux-gnu would be enough to get gcc to build i686 code. Following the book, I didn't add -march=i686.
> to know the instruction, but you didn't share it with the list. I No, I don't know the instruction/opcode, just the routine gcc was working on at the time, bugs.o. One suspects it's a 64-bit instruction, rather than one of the new "SSS[S]E" instructions. The Conroes may not have all of those on the i7, but have 64-bits and the kernel still compiles. > don't think I've used a pIII in this decade, so I don't have a lot to > suggest. I'm thinking it'd be a common problem for many cases of running LFS on a less "capable" CPU, i.e. code built on a 64-bit capable CPU on one that isn't, e.g. P4-Northwood. > Also, you haven't mentioned which kernel version - 7.7 had 3.19 which > is long out of support upstream. Sometimes, different .config choices > cause odd errors, and with luck those get corrected in later stable > kernels. FBBG ;-) , I've got 3.19 and optionally the 3.19.8 patched version. I haven't gone beyond that. But I think the problem is gcc that tried to use the invalid instruction, not that it tried to compile one. > So far, only gmp has been implicated in those sort of problems. Of > course, if it _is_ adding instructions which the current CPU cannot > execute, you can't recompile it in that system. I was watching these builds, so I noticed the -march was wrong during the gmp build, but it seemed OK subsequently. I tried to notice as things whizzed by. The gmp build has ABI=32, but nothing about -march. 8-( So, how to stop it is the question. 1) Would bits of gmp, mpfr, mpc get included in the generated code, or are those only needed by gcc itself? So, would everything have to be remade? Does anybody but the GNU gcc team know? 2) But would I really have to go back to Chapter 5 to correct gcc? AIUI, running the test suite is what requires deja-gnu, expect, & tcl. Adding those to the completed system should allow me to rebuild gcc-4.9.2 with -march. That would avoid using a known compromised, i.e. Chapter 5, gcc. 3) Is the glibc (and everything else) I now have also suspect? (Going all the way back to Chapter 5 would be nice to avoid.) I could do a CMMC on glibc on the i686, if the make would even work, or works with a recompiled gcc. > To be honest, even using any gcc-4.9 version on a pIII was not > particularly common - I believe that debian distros used 4.9.3 for a > while. Whether 4.9.3 had relevant fixes I don't know. But is this truly a compiler bug, or only to add -march to a gcc rebuild for CPU compatibility? Sound reasonable to you? The book sometimes addresses CPU/system compatibility, but maybe not in this case? > For old hardware, a recent memtest86 variant might show if your DRAM > has gone bad. Yes, I realise that if the box runs headless it will be > a pain to test that. It isn't headless, just in an uncomfortable place for hours of work. I'm tending to think this isn't a HW issue. > If it was me, and depending how desperate I was, I might be tempted to > build 'kgcc', i.e. a separate version of gcc and matched binutils > based on the instructions for LFS pass1 binutils and pass1 gcc, but > with both installed into a new directory - and then put that directory > first on $PATH both for yourself and for root when making > modules_install. Yes, I understand that. What do you think about just rebuilding with -march in the completed running system? (And I'd do that on my i7(!), so the original build system is "correct".) Granted, my pio package management will find everything(?) a "replacement" of a pre-existing file (I can't, as I would in other cases, delete the package first, of course), but the great thing about pio, IMO, is that I can carefully, apropriately diddle the script, so if it came to removing the package it will act as if the rebuild had never happened. Errm, maybe rebuild gcc on BOTH systems and diff the results? Extra work? > But if I was a gambling man I would suspect gmp. Apologies if I've "made a dog's breakfast" of this, but I'm just trying to understand the extent of the issue here. I've been building LFS systems for over a decade, but haven't learned what I haven't learned yet. I think maybe I understand, maybe. I don't want to bolix it more, nor do more work than necessary--itself an indication that the diagnosis was correct. OTOH, I don't want to convince myself this the right direction if it isn't! Commentary appreciated. -- Paul Rogers [email protected] Rogers' Second Law: "Everything you do communicates." (I do not personally endorse any additions after this line. TANSTAAFL :-) -- http://www.fastmail.com - mmm... Fastmail... -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
