Trouble Building glibc chapter 6
 

I am attempting to build glibc in chapter6 book 7.3

Since it reportedly took >17SBU's I walked away, expecting it to take a while. After about 24 hours it was still working. BTW, This is a core i3 notebook with 4gb of ram. I used a j5 make flag.

It appears to be getting stuck in a loop repeating the same thing over and over again, however there doesn't appear to be any errors. I tried it again without make flags and it appears that the problem is still there and occurs within the first few minutes.

Since there is no errors I wasn't sure what I could post. Here are the last few lines before it loops. It appears to iterate about every second or so.

I would rm -rf on the source and build dirs, and start afresh. After the configure, Run
Get on another terminal and view it with
When it has looped a few times, go back and hit Ctrl_C where it is making. Go over the error file and see what you can find.

I gave it a shot but I don't see any error's. It just repeats. Here is the repeating portion of the code.

Is this a dual core i3? If it is: -j5 is way to high. Use -j2.

Anyway: Maybe you should try building it without the -j flag and see what happens.

Since the problem occurred I have not been using the j flag at all. Also, I confirmed that MAKEOPTS is not defined.

BTW, not to argue, but LFS as well as many other sources recommend (# of cores) +1.

---------- Post added 06-17-13 at 03:07 PM ----------

Since the problem occurred I have not been using the j flag at all. Also, I confirmed that MAKEOPTS is not defined.

BTW, not to argue, but LFS as well as many other sources recommend (# of cores) +1.

That's the safe thing to do.

I'm not arguing, just asking. You _still_ have not mentioned how many cores your i3 CPU has..... We can only assume it has 4 cores.

Yes, it has 4 cores. regardless I am only using one thread.
So I don't suppose you see anything in the posted output that looks wrong? Other than the fact that it repeats, I don't see the problem.

It's looping in the build script, and they are not supposed to loop, ergo something is wrong.

Remove the -j option as has been suggested, A parallel build can cause errors, and at 17 sbus, you won't be there more than an hour. When you followed the instructions in post 2, did you grep the some_error_file for words like warning, error, found, and missing?

The -j option has been removed since before the first post.

as for your the error, found, missing and warning.

found and missing return nothing.
error and warning but nothing that actually appears to be an error or a warning. For example, below is a few lines from the bottom of the results for greping the output file. There are a lot of files containing the words error and warning.

Can you post the config.log file and the make command?

BTW: Just to make sure (business_kid already mentioned this); You did remove both the source and build directory before trying again?

Grep for Error (capital E!) instead.

Or also make -S > logfile 2>&1

Stops it on the first error. I'm fairly sure there is a mistake, and it's being repeated, which is the way things happen on LFS. Do check the md5sum, or sha1sum of the file

Ok, tried it again. clean build directory. Freshly extracted source.
from the build directory.

config command.

make command.
After 2 hours it is still looping at the exact same point as indicated above.

The md5 and sha1 check out. (all of them do). I have also deleted the archive and downloaded a copy from gnu.org. Same problem.

I've already asked (post #10), but you might have overlooked it:

Can you post the config.log file and the (output of the) make command?

I apologize, where would this config.log file be? It's not in the source directory. Also, I'm not sure how to post the entire make output as the error doesn't occur until the log file is over 6 MB.

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.

I suddenly remember a strange problem I had some time ago. I wanted to build a second system on a different computer. I tried to use the same toolchain, and I had completely forgotten that i used '-march=native', which was corei7. (Actually I still don't remember if I really used that for the toolchain, but I couldn't find any other cause for the problem.) I think it was perl that again and again got stuck in an infinite loop of untaring some packages, until all RAM was used and I had to reboot. Somehow I managed to login to a different tty and run, I don't remember if it was 'ps' or something else, where I saw something like 'tar <some package>' again and again, filling the whole screen.

I don't know if I compiled everything before perl on that machine, or if I compiled it on the first machine. I create packages so I could have just installed them, and continued building from there. When I realized what I thought was the problem, I rebuild the new system on the first machine, and made sure to have the right optimization for the computer I was building for, 'core2'. And then there were no problem with perl.

Thanks for making me remember my mistakes, so I can share them and maybe help someone... ;)

All LFSers and ex-LFSers have at least one experience of a build that went sadly wrong because of initial toolchain trouble causing issues much later on. If you get into the smaller packages in ch 6 without issue you're usually safe. GCC used to be the big stumbling block when I was doing it, and people using ambitious $CFLAGS settings. HLFS has/had a uclibc build that rarely completes.