Or
This last, just compare the two outputs... should be identical.

Either only works if you haven't yet deleted to build directory.

The new ld-new seems to work in chroot in eviroment. The cmp tool says it differes at line 1, byte 25 and the md5 is wildly off. Shall I try to reinstall binutils pass 2 (version I checked)?

I'm getting a nasty feeling this bit where we're trying to work from reconstructed log files could be very misleading, so I'm wondering if we're not chasing this down a blind alley. I think it is better to just start again. I know it's a pain, believe me, I've been there. It's why I have setup to script as much of this as possible. But the problem is that each step is so dependent on the previous one and toolchains are such persnickety beasts that trying to start again in the middle is similar to trying to rebuild a car that has been partially smelted down. Maybe it can be done. Are you sure you want to drive it in congested traffic?

btw... the two files are probably different because of whatever you did to recreate the logs. I enjoy helping with this type of thing, but the effort to find out what went wrong and we don't even have the original build output logged is bordering on the limit of even my patience. Sorry I'm not more help here. I've debugged enough of my own builds, and I sometimes do some changing of versions and trying out different build methods that I've managed to get through some irritatingly weird errors, but not without reliable logfiles to work from.

I relealize that. Since the new binutils, seems to work in the chrooted enviroment, I will chance an actual make install of the new binutils (I did make lots of backups for this install as it is my third attempt). Does the LFS book even have a notification that you should backup your log files?
If this fails and re-start, I think I will try the method a generated the log files for make with:
I hope I can get a stabilized compling enviroment in chroot by pursing this, but I too have that feeling it may not work.

Good luck. Don't hestitate ask if you run into another roadblock.

The gut feelings was right the complied tools just won't run correctly, but this time I will backup every build directory in a special backup folder. Is there a better sanity check to run after the initial compilers pass 2?

Rebuilding the tools got binutils back online, now currently xz is suffering this issue, maybe others.

Did you start over?

Wiped /tools and rebuilt it. I wasn't sure about the other directorys.

If you grep the logs:
what is the first point of failure?

Which logfile should I grep or all of them? I created a new thread for a new issue with glibc, as I was thinking this thread was ending its life, but the issues maybe related. Though, right it does not seem so.

Edit: I rebuilt xz in the chroot and it works (the error seems to have changed to "command not found" from it orginial state)
Though, here are a few build errors I found when rebuilding (or building) it:
In config:
In make install

I looked at your other thread. I feel certain that all these problems boil down to one common problem, but still we are only seeing the effects.

As for which logs to grep, yeah grep em all. You need to find the error that is first in the chain of errors.
If this really is the first error, then something is very wrong with the toolchain. The error in the make log looks to me to be a multiarch <-> non-multiarch problem.
I'm trying real hard here to be helpful. One log, two errors. Toolchain problem looks like to me. One possible problem, and be aware that I'm grasping at straws from
out on the thin ice, is that your host system gcc is multiarch or multilib.

Okay, I believe that it does it does have that, but I have basically started copy and pasting from the books. I will put together every log file I created in archive and upload them.

https://onedrive.live.com/redir?resi...347110C1%21416

Are you removing both the old source and old build directories before starting each new build?

About your logs: there is a binutils and a binutils-2 logs directory, but only a gcc-2.
I'm not sure it is helpful separating the stderr from stdin for the logs; doing something like:
or
will help keep the error output more in sync with the non-error output, thus leaving better clues as to what was happening at the time of the error. This is my preference, since typos are my most common mistake and are often such a pain to track down. I make this point because the most serious error I see so far is this one in gcc-2/make-err.log:
I don't get this error in my most recent run of gcc-pass2 and it would help to see what is being compiled at that point.

The reason there is a gcc-2, is because of a typo. tar overwrote the first one. I do extract the errors via 2>*err.log where star is the log name before it.