Gcc Sig 11 Fails, Small Config Machine, WorkAround

Rod Roark rod at sunsetsystems.com
Wed Mar 13 10:51:16 PST 2002


Consider also the possibility of defective hardware.  See 
http://www.bitwizard.nl/sig11/.

-- Rod
   http://www.sunsetsystems.com/

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



More information about the lfs-support mailing list