@wannessmet.. nice to meet you. I am an American living in China right now..

I can tell you this.. the problem is when you start to make the 2nd pass.. Binutils and then with Gcc.. it is a PATH issue in my humble opinion.. when using the switch --host=xxxx the tool chain reverts to using the old host compiler and it WILL build the Makefile.. by using the build switch --build=i686-LFS-linux-gnu then the system can't find the gcc binary (compiler). It is as simple as that.

What really burns me is while you are in the LFS environment and you do a gcc - v it will show you the host version specs.. you do a i686-LFS-linux-gnu-gcc -v and it will spit out the newly created gcc specs.. which means for sure the computer knows about the new binary and the correct path: /tools/bin

but to get the 2nd pass build to use the NEW binary gcc is the real challenge. At this point in LFS the second build will not find the gcc binary path..

And I don't want to hear I built the first pass modules wrong.. they went as smooth as a baby's butt without a hitch.. I think the problem really started when the "adjusting the tool chain" was complete.. I think the issue is there.. I have built the tool chain about 5 times now.. always the same problem.. trying to do a native build on the 2nd pass is a no go..

I will keep you posted.. by the way I am running an i686 machine with CentOS 5.6 and a Pentium IV processor.. 1 Gig of RAM.. older box but still very good and fast.. takes me about 5 minutes to compile, make, make install Binutils.. Gcc and Glibc are much longer..

Cheers,
Bob

0 members found this post helpful.

thanks Bob any help would be greatly appreciated, still stuck at the same thing here

@ wannessmet

I can tell you this, after the 5th attempt at trying to install Gcc (second pass, as I did get through the second pass of Binutils) it was a NO go. I researched this extensively and found out that certain gcc and glibc versions just don't sit well with each other. Some platforms will compile it and others won't. LFS is no exception. Depending on your host's gcc you may never get the LFS toolchain to compile on your computer. However, I didn't give up. In order to build a toolchain I finally went to a friend of mine who has the ttylinux website. I used his script to successfully build a Linux system and a toolchain. It was quite easy once I figured how how to install and run the xbuild script system: ttylinux-src-mp8 (download).. go to this website: http://ttylinux.net/

I found that these versions of gcc, glibc work well with each other: gcc-4.4.4 and glibc-2.12.1.. note with this you only need gmp-4.3.2 and mpfr-2.4.2 (no mpc is needed).. I also compiled with this mix the very latest Linux kernel: linux-2.6.39.3.. used the same binutils-2.21.. there was a glibc-port required: glibc-ports-2.12.1 and also a patch for the linux kernel: patch.2.6.38.3.patch..

My suggestion if you want to stay with LFS is experiment with different gcc and glibc versions..maybe try the versions I mentions above, BUT don't use really old versions as then you have a problem with the kernel being compatible.. you can see I just used gcc-4.4.4 instead of gcc-4.5.2. They say that glibc is pretty passive and the versions are not really as important.. GCC is normally (and the configuration) the problem.

If you are just trying to build a custom Linux system for your older computer then use the ttylinux website.. either download one of their pre-built versions or make your own system and/or toolchain.

Regards,
Bob

I'm going to try again with another box and see what happens. I'll keep you posted what I found.

Hi wannessmet and linux_tales,

I just want to mention that building LFS, using the books package versions does work and up till now (LFS 6.8) i've never seen the need to use different versions or to deviate from the book to get a working end result. I'm not only talking from personal experience through the years (started with LFS 5.1) but also from others. As long as you use the stable version, have a good host (preferably the LFS liveCD) and follow the book you will end up with a working LFS.

Building an LFS based system can be, depending on Linux experience, a daunting task and after years of following this forum I noticed that the first build will almost always fail. Deviating from the book, be it on purpose or by mistake, is the most common reason for failure and having a host that is not compliant is a close second.

In short: The book to build the current stable LFS version (6.8) does not contain any mistakes and can be used as is.

1 members found this post helpful.

Hi Druuna,

Greatly appreaciate your advice and I do agree to what you say.

It sounds a bit unfamiliar to me that a published book from Linux From Scratch wouldn't work on virtually all iX86(_64) based boxes unless it has some very exotic hardware on board.

And even if it were a problem in the book, I'd expect google to be full of matches things going wrong with LFS 6.8 resulting in the developers from LFS rectifying the problem within days. Since google doesn't have too many matches and LFS 6.8 is out for months now I'm rather convinced the book is right.

I'm a great beleiver in the PEBKAC principle and I'm quite sure this Problem Exists Between Keyboard And Chair . Only thing I'm trying now is to isolate the problem and try to understand why and where I got it wrong.

I'll give it another shot this afternoon with another box (which is a bit faster).

Since you're based in the Netherlands I suppose you'll understand the following:


Vele malen dank!


Wannes

Hi wannessmet,

You mention in one of your previous posts that you are trying to build on (very) old hardware. LFS 6.8 (more specifically glibc) might not work on that. Have a look here: 5.7.1. Installation of Glibc (the Because Glibc no longer supports i386, .... part). If your hardware is i386 you might want to try building an older LFS version. 6.4 or older. Glibc, starting from version 6.5 has this "limitation".

LFS still has older version on-line (including the appropriate packages):
- 6.4 books
- Older LFS packages/bundles

Hope this helps.

BTW: Geen dank

2 members found this post helpful.

Good news >> I got through this error using all the packages stating in the book of course.

Cause? PEBKAC (as expected )

In the previous paragraph I skipped following:

Also for some reason I didn't find out yet $LFS_TGT was not set and I compiled every time using an empty $LFS_TGT variable.

Maybe even some more things. I started from scratch again and reread everything and redid all the steps, checked whether every variable was set correctly and continued. I didn't get any more error messages.

So well, while writing this I'm compiling GCC pass 2 (hope that one runs fine). Most likely I'll run across some more hickups but I got round this one!

Cheers and thanks for the provided help here.

You're welcome

congratulations.. glad you were able to compile the tool chain. I managed to get through it too so everyone is happy. LFS is a great learning experience. Anyone interested in building Linux systems should spend time there..

cheers,
Bob

you will notice in the newest book change just made in the past day these changes were made:

--disable-target-libiberty --disable-target-zlib

and the new patch: gcc-4.6.1-cross_compile-1.patch

I knew my brain wasn't screwed up.. libiberty was being overwritten by gcc (when binutils had already written it) was one of the problems..

just saying! Nobody's perfect, including LFS

0 members found this post helpful.

Hi,
I asked you a few questions you never answered (post #11). The above indirectly answers one: You are building the latest SVN version and _not_ the latest stable version..... The SVN version doesn't come with any guarantee and content changes just about daily.

Providing that information _is_ important, especially when you post in an older already existing thread that deals with the stable version and start labelling LFS as not working/incorrect/wrong.

People use this LFS sub-forum as a place to get help, providing incomplete and incorrect/wrong information will throw them of track. For most it is hard enough to build LFS without getting mixed messages.

But as you yourself already stated: Nobody's perfect, including you.

1 members found this post helpful.

look, I know you think I am nuts.. I am trying to build 6.8 at this link: http://www.linuxfromscratch.org/lfs/view/6.8/ .. but LFS just removed a new posting of the book.. I saw it today.. it was using the Linux Kernel 2.6.39.3 and GCC 4.6.1.. these are brand new... I don't know what you are talking about when you say SVN. I have bookmarked the LFS website and have gone to that link every time.. the packages changed yesterday but are back to the same packages today.. it makes sense as the site may not be ready to post the newest book..

Anyway, it doesn't matter and I will not post here again. I have moved on as I have been able to build a good tool chain which I will use to build some standard and embedded Linux systems with. I simply needed a good cross-compiler on my CentOS box.. which I have and WHICH LFS WAS INSTRUMENTAL in helping me get there.

Regards,

Bob

Hi,
Nuts? No! Confused, probably. Both the kernel version and the gcc version you mention are part of Development/SVN LFS and not Stable LFS 6.8

Stable:
- GCC-4.5.2 - Pass 1
- Linux-2.6.37

Development/SVN:
- GCC-4.6.1 - Pass 1
- Linux-2.6.39.3

Once a stable book is put on line, no changes are made to it. Possible errors are mentioned in one place only: Stable - x. Errata and the link it provides doesn't mention any problems thus far with stable LFS 6.8 (Errata for the 6.8 Version of the LFS Book). This is the way it has been done for years (at least going back to version 5.1).

The development/SVN version will eventually be the new stable LFS version and it is in constant flux.

I'm glad to read you got it all worked out and are able to move forward.

I don't know how I got to the development link but I can see that is where I ended up.. anyway, not an issue now. I will bookmark the LFS development link for future reference.. I really like the (NEW) included switches in the "development" view:

--disable-target-libiberty --disable-target-zlib

this keeps libiberty (especially) out of the picture as Binutils installs it previously..

Cheers,
Bob