In the section of the LFS book (stable) I discovered that bash was giving off as as no such file or directory. I checked binutils and all of them have a similiar problem. bash works fine, etc works fine. I am working in the chrooted enviroment. ldd gives:
The PATH is set to:
Update: the as tool works prefectly in the non-chrooted enviroment, this only applies to the chrooted enviroment

Edit 1: from the host os ldd reports the LFS "as" as:

Log output for the failed build?

Requested output:

The highlighted part is the tuple that gcc was configured to build for. It should be x86_64-lfs-linux-gnu. Pass 1 and/or pass 2 of gcc builds were done for wrong target. Probably the the lfs user environment was incomplete, as per spec'd in http://www.linuxfromscratch.org/lfs/...vironment.html or the --target configure option to the gcc pass 1 build was mistyped, some thing of that kidney.

In that in case, why does the tuple you are talking about exist and have the same problem? Any idea of how to redo GCC - pass 2 without redoing everything past it? (I expect to redo somethings, but hope not to do so)

Well, I'll be darned. I remembered that one wrong. I should have double checked, but the problem might be with binutils pass 2. The tools built in binutils pass 2 should be installed in /tools/$ARCH-unknown-linux-gnu/bin. (It was the pass 1 that I was thinking of, that builds the initial cross tools and compiler). gcc is saying that it can't find 'as' in the exact location where it should be.
If that's the case, then how did the pass 2 compiler get built properly? It's really weird trying to debug this kind of thing with only partial logs and only the ones where the error occures. In my experience, an error in the 'current' build is usually caused by an earlier problem. I'm guessing too much here, so if you want to supply more logs maybe someone (even me if I can remember to make sure I verify my facts) can point you in the right direction. I apologize if I wasted both of our time here.

I would be happy to do that, but I need to know what logs to post and I was following what I believed the book's build policy.

Of course. I don't mean to be a jerk, though I may have been in my embarrassment at seeing I had jumped at the wrong conclusion, even remembered a few things wrong.

The logs to look at should be the chapter 5 binutils (pass 1 and pass 2) and gcc (pass 1 and pass 2).

Well, I did my best to recreate the logs. I am just now noticed something that seems a bit scary in the last 2 passes."...host tool"

There is a archive I generated of what I believe to be helpful:
https://onedrive.live.com/redir?resi...347110C1%21414

OK, I've not finished looking through, but there's a definite clue in gcc_pass-2/make_install.log. Permissions problem for directory ownership.
Another one that has me curious is line 115 in gcc_pass-2/make_errors.log; I've looked through the logs for my most recent build and see no errors where xgcc's backend (cc1) bombs like that. But that might only be a clue to something else.

Still looking, so I'll report back as I get more sorted out.

The reason I believe is due to the ownership being changing before the logs. I ahd to regenerate them and the make install logs are not very good doue to this. I am still to new to linux to unchown them.

Ah, well... take a look at binutils_pass-1/make_install.log. It says it all. Probably missed the chown command on /tools or it failed or something in that vein.

Oh, I see, so you'd done the chown in chapter 6 back to root ownership, then I guess.
Ok, I'll keep looking.

At the bottom of the binutils_pass-2/post_build.log, there is an error that makes me wonder if ld/ld-new really got copied to the /tools/bin directory:
If I'm right here, and the retargeted ld-new didn't get copied, then it would possibly explain xgcc's cc1 not getting linked in gcc_pass-2.

ld-new in tools/bin exists. Is owned by root, I generated the logs under the lfs user.
Anyway to compare the files?