GCC(segmentation faults) and LFS-6
declan.moriarty at ntlworld.ie
Sun Nov 14 11:07:59 PST 2004
On Fri, Nov 12, 2004 at 02:10:06PM +0000, ilja enlightened us thusly
> Sorry I didn't reply earlier. Inbetween LFS builds I am trying to finish my
> PhD. I know, it should be the other way round, but lfs is quite addictive.
> Non the less I put it asside the last few days.
> I would like to scream: "LFS-6.0 is a nightmare." But I am aware this is a
> comment from personal experience and it has really has nothing to do with
> the LFS project (or the developers) itself. What I mean is that I get the
> feeling there is a much more delicate interaction between the different
> packages since the 2.6 kernel, recent glibc's and gcc versions making the
> build very sensitive for errors. The LFS-6.0 build must put about 10x more
> strain on my poor old system. A system that has been rockstable (or so it
> seemed) for the day I bought it.
> I've done about 6 LFS-6.0 builds now, all of them failing in one or more
> ways. Either in the early stages or later on while adding BLFS.
> I agree with you Declan, and am aware that it is more likely me or my
> hardware are the source or the problem. But, I've successfully build many
> LFS-5.1 systems on the same machines. I've ran a 24 hour memtest recently
> without a single error. The heatsinks are wellpositioned and dustfree.
> Anyway, I don't give up easily. I've started again from scratch. I've set my
> BIOS to very 'mild' settings, and am logging all build activity. I'll get to
> the bottom of this. Thanks for your advice on how to go about it.
I'm not a 100% disciple of LFS; I don't like the system when it fails.
I wouldn't start a LFS-6.0 build now. There are some obvious problems.
1. GCC-3.4x is too <expletive deleted> fussy for the the
packages out there IMHO. We had this sort of thing with gcc-3.x as well.
The correct policy is to stay with gcc-3.x until it doesn't work, like
we did with gcc-2.95. This isn't LFS's fault - it's the fault of over
enthusiastic 'beta' type releases.
2. For programs like OO, Evolution, Mozilla, Firefox, the build
from source does not achieve the lfs goal of making you familiar with
the software. Instead you grouch and plead on mailing lists until some
programmer sorts you out and tells you what to do. You follow blindly.
You have screwed up plenty, learned nothing, and controlled nothing.
This is in stark contrast to things like ghostscript or kernels, where
you can add a host of drivers and options at build, which suit your
3. The whole toolchain area seems a nightmare in finding a
version of glibc, gcc, binutils and kernel headers.
Given the above, blfs imho cannot hold the middle ground and
build a system for all people without putting a hell of a lot more work
into it; what happens is that anyone who wants any special area
developed is on his own. It would be better to have this sort of thing:
a. server/router/firewall blfs (no X, apache, xinetd, iptables etc)
b. multimedia blfs (Hotplug, webcams, audio, ripping)
c. Programmers/cutting edge blfs (For Masochists :-).
d. Bootdisk /Boot cdrom "Distro" blfs. (
e. <insert your own here>
All starting from the same basic lfs. I'll stick with older versions for
the moment anyhow.
With best Regards,
More information about the blfs-support