> > ...  I'm going through your thread "with gun and camera".  I don't have
> > any of the logs from that build, they're only for debugging a package's
> > build.  Let's see what shows up.
> >
> Thanks a lot :)

May I offer something based on my experience I hope you can take as 
constructive criticism.  It's the quote (I don't know whose): "Not everything 
that can be done, should be done."

When I build my (B)LFS system(s), I intend to use them for a long time--too 
long Bruce and Ken would argue. ;-)  Anyway, it's most important that the 
system gets built correctly, and that I *know* it is.  If LFS has any glitches 
the whole system will be impeachable.  So I build on the plain hardware, 
nothing that could compromise the environment.  And even with the wrappers I 
put around both books' instructions, I closely follow the LFS book step by 
step.  Is that the *only* way you can do it?  No, but if not, then you have the 
responsibility for validating the differences are immaterial.  One job to do is 
enough for me.  I don't need to do the second too!

It seems to me you may actually "know too much", running ahead, doing too much 
extraneous stuff not in the book.  I see you running this and that trying to 
justify this or that got built actually OK.  If you follow the book correctly, 
it will be OK, the other stuff is a distraction and confusion.  There's an 
acronym around here: FBBG!  (Follow Book, Book Good!)  I suggest you get out of 
the virtual machine, go back to "bare iron" and do what the book says, and 
*only* what the book says, every step of the way.

>  Sorry for not understanding, when u mean 64-bit system u refer to the VM
> host which is Ubuntu 12.04 32-bit? Or my laptops OS which is windows 10
> 64-bit? i don't get it why is it a problem, since my VM runs on 32-bit.

I mean "bare iron" 64-bit hardware, with a 32-bit *nix OS running on it.  Your 
Linux LFS system will be an OS, with an interface to and running real hardware. 
 It needs to work with the real thing--some of the software you will build will 
look at that hardware, gmp for one specifically!  What you have is 64-bit 
hardware, running MS (not exactly known for embracing Linux) Windows, preparing 
either a hardware-virtualized or paravirtualized 32-bit environment for your 
32-bit Ubuntu, to build something that will work in a totally different 
real-world environment.  I wouldn't guarantee that!

> > - I agree with Thanos that the "ldd /bin/bash" is a major problem, and
> > means you must backtrack at least as far as 6.33, and with your diagnosis
> > that there was already a problem at 6.17.  "ldd /usr/bin/file" shouldn't
> > still be looking at /tools, which strongly implicates 6.10, "Adjusting the
> > toolchain".
> >
> >
> A strange thing that i have not noticed is this.

No!  Don't go noticing strange things!  It will only confuse you--as you are 
telling me it has.  Just follow what the LFS Team has laid out for you.  If you 
want to go your own way, build your own Linux system as a Master's Degree 
project, fine, go do it, but LFS isn't that.

> Binaries 6.12 - 6.16 compiled with the old gcc have the correct paths on
> shared libraries on ldd.
> Thus because i keep vm snapshots, i skipped building 6.17 gcc and moved to
> 6.18.

That's all irrelevant!  It involves identifying what the environment at each 
snapshot you may or may not have been.  That's not the job any of us are 
volunteering for.

I'm sorry to have to tell you this, but none of us are going to analyze what 
you're telling us you did, and showing us in bits and pieces, and tell you 
whether it's right or wrong and why!


Paul Rogers
Rogers' Second Law: "Everything you do communicates."
(I do not personally endorse any additions after this line. TANSTAAFL :-)
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?


Reply via email to