On Sun, Jul 31, 2016 at 01:23:42PM -0700, Paul Rogers wrote:
> > 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.
>
Since you are replying to me, I meant that you didn't tell us the
exact error message from trying to compile the kernel. Without
that, every suggestion will be guesswork.
> > 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.
>
If it was a common problem, I hope we would have heard about it.
> > 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.
>
That thought occurred to me afterwards, but deliberately building an
old out-of-support kernel is only desirable if you are debugging a
problem with a current kernel.
> > 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?
>
I don't recall anybody wanting to add -march. There was at least
one thread a while ago (probably in the last year) about gmp causing
a problem, and the answer is to copy the configfsf.{guess,sub}
scripts over gmp's own config.guess and config.sub. Probably at
least two threads, and one of them had a lot of detail along the
way.
> > 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?
>
I haven't had the problem, so I don't know if adding -march will
work: I've never really understood the details of why gmp is used,
but telling gcc to create instructions for i686 might not alter what
gmp is doing.
> > 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.
On reflection, I suggest you rebuild gmp on the i7, using the
configfsf scripts, but do a DESTDIR install and then copy the
DESTDIR over to the tualatin). Then retry the chroot kernel compile.
Iff that now compiles, you can then do a real install on the build
machine.
If it works, this should be quicker than rebuilding gcc.
ĸen
--
`I shall take my mountains', said Lu-Tze. `The climate will be good
for them.' -- Small Gods
--
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
