Glibc-2.2.5 compile error in chapter 6 of LFS 3.2

Bill Maltby LFS Related lfsbill at wlmlx1.wlmcs.com
Mon Mar 11 14:17:13 PST 2002


Ken,

That's closer to my 200MHz Pent-MMX. It has 64MB too. But it had
plenty of swap (128MB -p1, and 132MB -p2). I had some problems on
it that were solved by reworking my shells to reduce memory usage.

What is your swap size. If it's not >64MB, I wonder if swap is biting
you too. On my little machine, I saw the system swapping everything it
could, including kernel initiated daemons.

BTW, my semi-automation 0.4.2 beta stuff has been successfully run to
completion on a Slackware 8.0 as well as my in-house units. It runs
each chapter automatically to completion through chapter 9 with one
interruption for password change. It is also all bash for many good
reasons.

If you want to use it for non-commercial/non-business purposes, let me
know offline at

    billm at wlmcs.com

and I will be happy to send you the tarballs in return for beta feedback.

Bill Maltby
billm at wlmcs.com

On Mon, 11 Mar 2002, Ken Moffat wrote:

> Bill, 
> 
>  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
> reputation. 
> 
>  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
> tree.)
> 
>  Hmm, maybe I'll watch glibc try to install in a little while, you never
> know.
> 
> Ken
> 
> 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
> > scripts.
> > 
> > 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
> > usage.
> > 
> > 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
> 

-- 
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 mailing list