Gcc Sig 11 Fails, Small Config Machine, WorkAround
Bill Maltby LFS Related
lfsbill at wlmlx1.wlmcs.com
Wed Mar 13 12:52:05 PST 2002
Already had done that Rod. But when I run Micro-2000 diags on it
all is OK. Plus, if you missed earlier threads, I had same symptoms
on my 200MHz RH 6.2 64MB, but to a lesser degree. A good portion is
engendered by my "... aggressive" shell coding style to minimize
fork/exec, etc. I was able to get around the probs on the bigger
machine by carefully backing out some of the agressiveness for a
couple of packages, like glibc, ncurses, etc.
That allowed my generalized semi-auto to succeed on both RH 6.2 and
LFS 20020219 on that hardware. Prior to the adjustments, both had
Side note: I did a bash bug when I recognized that I was bumping up
to some Linux/mm/bash/make wall there. The folks at bash responded
quite quickly and I got confirmation that there were indeed some
platform-configuration-dependent limitations that would come into
play with the style I was using.
It surprised me because I expected that VM with adequate swap, etc.
would not result in that situation.
Oh well, thst's what make "experience" useful I guess.
billm at wlmcs.com
On Wed, 13 Mar 2002, Rod Roark wrote:
> Consider also the possibility of defective hardware. See
> -- Rod
> On Wednesday 13 March 2002 10:44, Bill Maltby LFS Related wrote:
> > Ahhhh, at last a potential workaround (_not_ a fix).
> > This is somewhat verbose, but _if_ anybody else hit a brick wall,
> > just wanted to let them know that tenacity will reward.
> > I now have my small-footprint machine booted on LFS. My intent is
> > to probably leave it there.
> > I hope the below is useful to others.
> > As some of you may be aware, I had experienced various failures
> > apparently related small RAM/SWAP and the horrendous bloat of
> > requirements for glibc, gcc, etc.
> > Well, on the small machine, I finally decided to manually do
> > some things. In the install-kernel phase, I had the urge to
> > to get kernel built regardless of how many different places it
> > failed with gcc signal 11.
> > Feeling that this was an "accumulate but don't free resources"
> > error, I felt that taking advantge of what make does to reduce
> > the resources needed in a pass might yield success (haltingly).
> > What I did was at each place it failed, rm the .o it was trying
> > to make (if it existed), ran sync;sync and ran the make bzImage
> > again. Each time, it would blithely skip doing stuff that make
> > recognized at not being needed (it had just finished making
> > some component) and proceed. When it got to the component that
> > had been removed (or never created) it make it and continue
> > to the next step.
> > This worked on exec_domain, char/tty_io, scsi drivers, reiserfs,
> > etc., etc., etc. In most case it would finish up the failed
> > directory and proceed to the next major directory. There were
> > a couple of exceptions wherein it failed in the same directory
> > multiple times, but on successive modules. Ipv4 net being the most
> > notable.
> > I tenaciously continued this process and in each case the make
> > properly made the missing/removed component and progressed further
> > down the tree.
> > It will be interesting to see if it behaves the same on the resulting
> > LFS platform. In there I don't need to run with chroot, so maybe...
> > Now, the good news is I can automate this.
> > The bad news (multitudinous) is it will run slowly if automated.
> > It is aggravating if you're running mannually.
> > I perused the man page, but saw nothing helpful. Maybe one of
> > you with more gcc knowledge knows a command-line switch that
> > would suppress the symptom entirely?
> > I'm going to browse for the GCC manual and see if it mentions
> > these signals and offers a solution for small-footprint machines.
> > Also, if I can find a FAQ on it, maybe it's been addressed there.
> > Question? Is this _possibly_ a reporable bug?
> > What about alternative compilers? Risky to use with LFS? Anybody
> > got some hard facts on my symptoms or a less-kludgy workaround?
> > Bill Maltby
> > billm at wlmcs.com
> 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