Gcc Sig 11 Fails, Small Config Machine, WorkAround
Bill Maltby LFS Related
lfsbill at wlmlx1.wlmcs.com
Wed Mar 13 10:44:18 PST 2002
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
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?
billm at wlmcs.com
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