It is created in the build directory or the glibc source directory.

Compress the file using zip/bzip/tar/.. and upload that.

Alright I have the config log and make logs.

to clarify:
This was all run on a single thread.
Freshly extracted source directory and empty build directory
I used the exact syntax for the config that was specified in build 7.3
for the make command I used

The locations of the files are:

http://www.pages.drexel.edu/~dmf86/glibc-logfile.gz
http://www.pages.drexel.edu/~dmf86/config.log

line 8892 contains the first line of the loop. I stopped it after a few iterations.

Grabbed the logfile, and my attention was caught by lines 8892, & 8893
That is suspicious, as make should clear off and build something else. If you stop a make after it has done several directories, it is usually capable of running down through what it has done without recompiling and taking up where it left off. That points to possibly
1. A mistake in the makefile causing it to loop.
2. Maybe some weird issue with writing notes to itself.
3. Something else that my devious mind cannot conceive of.

I guess I could try reverting to 2.16. At least that will help me zero in on the problem

Well, I tried 2.16.0 and got the exact same looping error. It seems to me that this probably rules out a makefile error as I doubt the error would make it through two releases. I'm wondering if this could be some kind of problem with permissions.

I guess we can rule out glibc itself as the culprit, something must have gone wrong earlier in the build process.

Did you check and re-check if the first few chapters in chapter 6 were done correctly? I do hope for you its a problem in chapter 6, going back to trouble-shoot chapter 5 at this point would be very hard to do.....

yeah... sadly if it is a problem from previous mistakes it's probably chapter five. I have re-ran through all the steps up to this point a dozen times. I'm seriously considering redoing the entire chapter five with all of the make checks.

That might be a good idea.

Running the tests in chapter 5 can be problematic and some test cannot be run at all (details are in the specific build chapters).

I'm just worried that I'm not going to see any difference. Oh well. I guess I have nothing else to try.

Has anyone successfully build book 7.3?

Multiple people have (me being one of those).

Me

+1

Understandable.

You'll just be re-doing the tools. Mostly. In the context of a complete BLFS project, that's not so bad. Probably one evening of work. Some other ideas to consider might be using another host system. It's Debian now, right? Try your Slackware system. That was the last distro host I used. Another idea is to consider building a 32-bit system. Those ideas are mostly guesswork. Thinking out loud mostly, and not really based on much. Nor guaranteed.

I had no problems with it.

One other consideration: The build tools on your base system must be good enough, and up to date enough to build chapter 5. One suspect is always the kernel headers. In the time I was doing LFS, some uclibc based builds were failing with weird errors, and it was traced to an older kernel headers package than the kernel itself (headers 2-15, kernel 2.29 or some such). These kernel headers only affect what you build. They do change occasionally.

Right now, on Slackware-14.0, I have kernel headers-3.2.29, and kernel 3.8.8 - not a good mix. If I hit build difficulties, the headers would be the first thing I'd change. You can simply run
make headers check
make headers install
in the kernel top source to install new headers, or install the headers from the updates, or current.

Don't update the kernel api headers.
http://www.linuxfromscratch.org/lfs/...08/kernel.html
The kernel api headers should be the same as was compiled in chapter 5. Once I tried to use newer version in chapter 6 (3.8.8 instead of 3.8.1) and I had strange problems, where things "mystically" didn't compile. Switching back to the same version of the kernel api headers as I used in chapter 5 solved the problem.

Funny how things change. . . It was 10 years ago. Agreed, Lennie. I was somehow thinking if all else fails, replace the headers before starting on ch 5. But I didn't say that, or nearly. Any switch midway would be a disaster. Thanks for tidying up for me.