Glibc-2.2.5 compile error in chapter 6 of LFS 3.2
ken at kenmoffat.uklinux.net
Mon Mar 11 12:23:02 PST 2002
there's definitely some correlation with my glibc install problem (I'm
also seeing _occasional_ signal 4's on building glibc), but my error
isn't random, it's identical each time.
My LFS box is a K6 with 64Mb. Runlevel is 3, with typically three
terminals open. `top' looks fine at the moment (not attempting to build or
install anything, and it's running with the `-rmap' VM which has a good
I got as far as automating the chapter 5 packages (bash, of course - perl
might be easier, but how would you run in at the start of chapter 6?), but
from there on (/etc/passwd, onwards) it was all done by hand. And I'm far
too wary to use anything beyond CFLAGS='-O2 -march=i586'. (And yes, I did
remove these CFLAGS after the first error and try again with a clean
Hmm, maybe I'll watch glibc try to install in a little while, you never
On Sun, 10 Mar 2002, Bill Maltby LFS Related wrote:
> Gerard and Folks,
> I've been following and finally figured maybe what you're seeing is
> somewhat related to what I've seen. Consistently inconsistent fails
> in the glibc install process.
> In my case, I believe I've worked around it, but maybe some of my
> conditions apply in the questions you've been fielding.
> My BILLS semi-automated stuff is all bash. I am developing on two
> low-resource machines. A 200MHz 64MB Pentuim-MMX, RH 6.2 and a
> 166 MHz AMD 32MB, RH 6.0.
> Now the deal was that I was going for max performance, damn the
> memory usage. I was suitably punished for my transgressions.
> Symptoms included random failures to install in glibc (the most
> persistent and sever case), gcc, e2fsprogs, ncurses. The mode
> of failure was not consistent. Sometimes syntax errors in C code,
> sometimes C compiler failure with signal 11, sometimes C syntax
> errors in different places.
> After eliminating the possibility of hardware error by pure
> dint of faith, I began to suspect that my wanton use of scarce
> resources was somehow related, even though this is not a Micro-
> soft piece of... work. So I began "unoptimizing" some of my code
> a little bit at a time and managed to eliminate all the failures
> _except_ glibc's.
> Hmm... said I. I had noticed that glibc with all i18n stuff all
> being done was a world-class hog. To clean that one up, I had
> to absolutely inline all the code, effectively having only one
> level deep nesting.
> Where I think this _might_ relate is this. Are the folks having
> problems on limited resource machines? Are they running from
> script? Are their machines in states 3 or 5? I have found that
> all these things combined and individually seem to expose some
> kind of weakness somewhere in the Linux/bash/make when it comes
> to managing memory.
> Various levels of progress can be made by running single-user
> or typing all commands manually (no bash scripts) for the heavy-
> hitters or, as I had to do, simplifying to some level all the
> Since my stuff was scripted and no changes were made to my chapter
> 5 scripts in achieving success, I know that the static compiles
> were done correctly. But glibc still failed until I reduced memory
> Now just tonight, gcc failed on the 32MB 166MHz RH 6.0 with a
> signal 11 in chapter 6. And glibc tried to enter an infinite loop.
> But armed with my new-found knowledge, I shut down X, nfs, inetd and
> any other non-essentials and glibc finished. I am now rerunning gcc
> and expect success.
> I don't know if any of this is related, but the stuff I've seen
> in the articles was beginning to look awfully familiar.
> Bill Maltby,
> billm at wlmcs.com
pppg_penguin.linux.bogus 2.4.17-jl15-ll 2011.95 BogoMIPS
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-support' in the subject header of the message
More information about the lfs-support