On Mon, Jul 08, 2013 at 09:56:14AM -0500, Dave Wagler wrote:
> This error occurs while compiling gcc-4.7.2:
>
> ../../../gcc-4.7.2/libgcc/libgcc2.c: In function '__multi3':
> ../../../gcc-4.7.2/libgcc/libgcc2.c:559:1: internal compiler error:
> Segmentation fault
>
> LFS book 7.3, chapter 5.5
> Host: Korora 19 KDE amd64 (this installation is dedicated to this LFS
> sysgen)
> CPU: Intel(R) Core(TM) i5-3550 with 4 processors
> Memory: 16GB with 32GB swap available
>
> The list of version numbers of critical development tools is in the
> attached console log. The log was recorded with the script command, so it
> has that funny formatting.
>
> There were no known significant deviations from the book. There were
> various problems (confusions?) with permissions and ownerships that
> required use of sudo in places not mentioned in the book, but the actual
> commands were not changed. Specifying 'make' or 'make -j2' instead of 'make
> -j4' doesn't change anything.
>
I'll start by worrying about the need to use sudo - /mnt/lfs and
all its directories should be owned and writable by user lfs. A
glance at your log shows that user dave seemed to be using sudo to
become user lfs. That sounds ok in itself, but less convenient than
doing things the book's way (become root, then su lfs for the build)
> I did a web search for the error message, but there are many different
> problems that cause segmentation faults. The only thing I saw that looked
> significant suggested using lower optimization levels.
>
Historically, segmentation faults when compiling gcc were often
caused by system stress (power supply being overstressed, or
thermal, e.g. build up of dust around the case fan(s) or lack of air
coming into the case). On modern kit lm_sensors will often tell you
about the temperatures (i.e. on the host distro - it may need a lot
of i2c and hardware monitoring kernel modules, but distros usually
build everythign as modules). I suppose that if your room is
abnormally warm at the moment that could also trigger cooling
problems.
For the power supply, I don't know of any easy way to test if it is
adequate. Recent power supplies seem to hold out well until they
die, so unless you have added extra things (drives, fancy graphics
cards) I tend to assume the PSU is probably ok. Mains power quality
might also have an influence (brownouts).
Also, memory sometimes goes bad. If all else fails, an extended
run of memtest86 or memtest86+ might show problems.
But before that, I'll mention my own anecdotal experience. Early
last year I bought an AMD Phenom (4 cores). Everything worked fine,
but from time to time it wouldsegfault while compiling with make -j
4. When that happened, it often continued to segfault even with
make -j{3..1} and clean source.
In those circumstances, as root
#sync; echo 3 >/proc/sys/vm/drop_caches
solved the problem and allowed me to continue - usually using make
-j3 to avoid the problem recurring.
Lately I've been looking at this again, and using current kernels.
I haven't done a complete build (LFS and then my current desktop)
like this, but I've done a significant amount of updating and it now
seems to be working fine. I conclude that something in the kernel
might have been triggering the problem.
Whatever, I suggest that you sync and then drop the caches. If the
problem happens again, repeat and try with -j3 or less. If you have
information from lm_sensors, take a look at that in case it points
to a problem. After that, run one of the memtest versions for
several hours.
> I have been using various linux distros for several years, so I am fairly
> familiar with how to use the basic system. However, this is the first time
> I have tried anything like this sysgen, so I know very little about the
> make process. For example, I don't know how to run make with a different
> optimization level in the compiles.
>
If you ever want to do that, google CFLAGS (and CXXFLAGS). Not
every package supports passing CFLAGS in the environment, but gcc
certainly does. Then again, the defaults in gcc should be perfectly
fine, and an i5 shouldn't have any difficulties with regular options.
> Any help will be appreciated.
> --
> http://linuxfromscratch.org/mailman/listinfo/lfs-support
> FAQ: http://www.linuxfromscratch.org/lfs/faq.html
> Unsubscribe: See the above information page
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
