I just started on an LFS build. I believe I followed all the instructions in version 5 of the book, but when I try to run the configure script for binutils, I get:
gcc: installation problem, cannot exec `as': Too many levels of symbolic links
It then goes on to whine about how gcc doesn't work, and of course it doesn't it can't find its assembler. I googled for the answer, and someone else has already gotten this problem before, but all the dialogue didn't make sense to me. Could anyone please help?

What was the answer you found - maybe someone can explain it and help you solve the problem.

When I googled for the full line of the error message I gave you, I got only one result. If you want to read the full dialogue, go to http://linuxfromscratch.org/pipermai...er/019414.html and continue on in that thread. The error messages this guy got are very similar to mine, so I think we might have a similar problem. Here are some things I noticed:

I did not set CFLAGS; I don't even know what that is.
Both gcc and as are executable as lfs, and are both in the path.
I'm not using any hints or the CVS version. I'm using the current 5.0 release book and following it literally.
I also had an error about symbolic links when I tar xvjf-ed the source, as well as when I ran the configure script. For some reason, using bunzip2 and tar seperately gave me no problem. (I suspect this might be helpful.)
I'm doing this on a fresh install of Mandrake 9.2.
My ~/.bash_profile looks just as it should be.
My CC environment variable is not set to gcc, but during the configure script started using gcc, so this should not be a problem.
I have personally set no symlinks anywhere around here except for the one between $LFS/tools and /.

Hope this helps.

I just had a similar issue occur on an beginning another build. Have you made a symbolic link on / to point to a directory inside your $LFS, and then included this inside your path? Changing that to an absolute reference the directory inside your $LFS works to prevent the problem - but, do not change the argument to --prefix, as that would break the chrooted stage. I will continue with this build, and will notify you if changing that path reference causes problems elsewhere.

Well, I deleted the $LFS/tools and /tools directories, and experimented a little with the links. I made a silly error trying to link to the /tools directory as a normal user, but learned something in the process. When linking $LFS/tools to /, ln whined about my permissions and said that I couldn't link /mnt/lfs/tools to //tools. That's right, two slashes. That just looks totally wrong. So apparently when I ran a program that executed another program (like gcc running as, or tar running bzip2), it gave me an error about an excess of symbolic links. I have no idea why, but at least I understand that having my $LFS/tools directory linked to //tools when the first item in my path is really /tools will not help at all later on.

Anyway, I think I might have a solution. I tried linking the other way around, meaning I linked /tools to $LFS/tools instead of $LFS/tools to /tools, so now ls-ing / shows /tools -> /mnt/lfs/tools. I then ran the configure script and it worked. Having the real directory be $LFS/tools makes more sense to me, because then when I chroot I won't have my new /tools directory linking to something which doesn't exist. Am I just totally wrong, or will this work?

That is the way around the directories should be, your logic in the second paragraph is correct.