In Pass 1, after I compiled and installed GCC 4.1.1 to /tools, I checked the location of the 'specs' file for the newly-compiled compiler. returned simply:
I cannot, therefore, edit the specs file to point to the new linker from binutils - the specs file does not exist.

Where is the default location of the 'specs' file specified when compiling?

EDIT: I just found another post dealing with this issue. Will the LFS book be updated for GCC 4+?

Development LFS is GCC 4.0.3. Waiting for GCC 4.2 to appear - and for GCC 4.1 to be ready to become main compiler for LFS.

Yes, I tried it too. And get stuck but its because I did not Follow The Book I have decided to build LFS with newer versions and using instructions from stable LFS and development LFS.
Ok, the solution is here:
http://www.linuxfromscratch.org/lfs/...adjusting.html

As far as I understand GCC since version 4 has changed specs dumping mechanism so the solution above creates specs file in the new manner.

Also I can warn you - if you decide to build glibc with libidn as suggested in development LFS, it will be kinda hard in chapter 6. If you wont use the sed command to modify test-installation.pl script as Development LFS suggests, glibc install will fail because default script will test toolchain in /tools/ not the new glibc in chroot environment. And you did not compile libidn in glibc in chapter 5, did you?
But if you will apply this sed on test-installation.pl from Development LFS then install will fail again because there may be some toolchain problems which produces un-executable executables if linked to all fresh glibc libs. I managed to get it install anyway and if you'll get the same problem I will be glad to tell the solution. It is just a little hack to that perl script, I can tell that after Re-adjusting the Toolchain in chapter 6 (btw in development LFS this chapter again shows how to modify gcc specs file nicely) the unmodified test-installation.pl script works just fine!

Good luck in experiments! And I wish you a stable LFS

No thanks.. I wish myself a reliable development LFS... And I do use jhalfs for rebuilds - I've failed enough builds not to want to do it once more.

Yes, I understand. I have had many troubles since I started experimenting. But the first stable LFS 6.1 was just fine, I followed the book and everything complied well. After that I decided to dig deeper and mess up witj LFS Dev. To avoid rebuilding everything in case of errors I use VMWare Workstation and many snapshots to fall back in case of errors. Of course, if the target is a serious stable LFS then experiments are dangerous waste of time I am just learning Linux and LFS for me is just like a game for now, but I am sure it will turn out to be more serious than I think now.

Ah. It still makes fun for you. Well, real fun is when development LiveCD contains some packages and nALFS. And profile for nALFS which - how did you guess - wants another version of some packages. And did you have fun when bash 3.1 suddenly made a lot of configures stop working. Well, it was their fault to carry typo. It was bash2 fault to run them. Nevertheless.. Also it's a good practice to shut down at really random moment. I've got a bonus - udev did not work after reboot. By the way, now I don't use it. I just don't like idea of it breaking after every kernel release. As for real experiments - I experiment with package management using unionfs. Now I'm waiting for funionfs 0.5 - I've submitted patches needed for such use, and they will be probably included.

Good Luck!..

Yes, it was a bit funny to fail coreutils test because some header files had modification time in the future and running tests as user dummy required to recompile some files..which could not be done because of "dummy" user restrictions. The problem was VMWARE Workstation clock - it never shows the right time and date. So I had to "touch" all the headers to get through the tests. But it took all the day to find out the problem.
Another problem was with groff - I wondered why did they use version 1.19 in Stable LFS and 1.18.1.1 in Dev LFS. Now I know why - 1.19 does not compile on Dev LFS - it just gives those nasty "bla-bla was not declared in this scope" errors.
And so on. It is fun if someone has a lots of time but a real pain if you want to get LFS ready ASAP.

In the last case you look through errata, think out workarounds and just run jhalfs on stable LFS branch. Or, even better, you take release LFS CD and run nALFS. Ok, now go download BLFS profile&packages - I mean stable - and you can run next nALFS/jhalfs step, but what is the difference with gentoo this way, except for normal rc.d?