Running nALFS freezes the machine

Kevin P. Fleming kpfleming at
Fri Jan 23 07:30:54 PST 2004

Chris Martin wrote:

> Kevin> Yes, using different glibc's and gcc's will certainly produce
> Kevin> different size binaries.
> The differences are quite large (the configuration of nALFS was the
> same: just --prefix=/opt):
> 52376 Jan 22 10:55 ../nALFS-1.2.1-lfs5.0boot/./src/src_nALFS-parser.o
> 11748 Jan 21 11:12 ./src/src_nALFS-parser.o
> 28056 Jan 22 10:55 ../nALFS-1.2.1-lfs5.0boot/./src/src_nALFS-win.o
> 14908 Jan 21 11:12 ./src/src_nALFS-win.o
>   659 Jan 22 10:55 ../nALFS-1.2.1-lfs5.0boot/./src/.libs/nALFSS.o
>   671 Jan 21 11:12 ./src/.libs/nALFSS.o

This is most likely an optimization issue; also if you are comparing 
1.2.x to pre-1.2.x you will see large differences due to the use of 
inlining in the older versions. Another possibility is that one of these 
compiles had "-g" in CFLAGS for some reason, which produced debugging 
information in the object files.

> Running it from the SuSE installation on the machine (greyarea) is
> fine. The existing LFS-5.0 installation on greyarea was created
> running nALFS-1.2.1 under SuSE 9.0 and runs without trouble (except as
> noted above ;) ).
> Could there be something subtle in the configuration of the kernel?
> The configurations of all three machines are derived from addedvalue's
> but I have no idea how to check that something vital isn't missing
> (there have been no kernel panics or anything else untoward).

It could be, one possibility if you can manage it is to set up a serial 
console for the kernel, so if there are any messages that you aren't 
seeing because of the crash you could still capture them. Otherwise 
you're going to have to add some type of "telemetry" to your profile so 
you can at least find out during what part of the build it's failing.

More information about the alfs-discuss mailing list