if [ x"-fpic" != x ]; then \ /var/tmp/portage/sys-devel/gcc-4.4.4-r2/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.4.4-r2/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -c -DHAVE_CONFIG_H -O2 -pipe -march=athlon64 -g -ggdb -I. -I/var/tmp/portage/sys-devel/gcc-4.4.4-r2/work/gcc-4.4.4/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -fpic /var/tmp/portage/sys-devel/gcc-4.4.4-r2/work/gcc-4.4.4/libiberty/fibheap.c -o pic/fibheap.o; \ else true; fi /var/tmp/portage/sys-devel/gcc-4.4.4-r2/work/gcc-4.4.4/libiberty/fibheap.c: In function 'fibheap_delete_node': /var/tmp/portage/sys-devel/gcc-4.4.4-r2/work/gcc-4.4.4/libiberty/fibheap.c:258: error: 'LONG_MIN' undeclared (first use in this function) /var/tmp/portage/sys-devel/gcc-4.4.4-r2/work/gcc-4.4.4/libiberty/fibheap.c:258: error: (Each undeclared identifier is reported only once /var/tmp/portage/sys-devel/gcc-4.4.4-r2/work/gcc-4.4.4/libiberty/fibheap.c:258: error: for each function it appears in.) See to-be-attached build.log and emerge --info.
Created attachment 260405 [details] /tmp/emerge--info.txt
Created attachment 260407 [details] /tmp/gcc-4.4.4-r2-build-head.log See the full build log at http://ohnopub.net/~ohnobinki/tmp/gcc-4.4.4-r2-build.log . I here attach the head and tail of the log...
Created attachment 260409 [details] /tmp/gcc-4.4.4-r2-build-tail.log
if the full log wont fit, then simply compress it and post that go into the build dir: /var/tmp/portage/sys-devel/gcc-4.4.4-r2/work/build/x86_64-pc-linux-gnu/libiberty and run: /var/tmp/portage/sys-devel/gcc-4.4.4-r2/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.4.4-r2/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -E -dD -DHAVE_CONFIG_H -O2 -pipe -march=athlon64 -g -ggdb -I. -I/var/tmp/portage/sys-devel/gcc-4.4.4-r2/work/gcc-4.4.4/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -fpic /var/tmp/portage/sys-devel/gcc-4.4.4-r2/work/gcc-4.4.4/libiberty/fibheap.c -o fibheap.i then post the fibheap.i file as an attachment
Created attachment 260474 [details] fibheap.i
Created attachment 260475 [details] gcc-4.4.4-r2-build.log.bz2 I didn't think of compression, but that works very well. Here's the full build.log.
limits.h isnt being included in your fibheap build. this is because it isnt being detected by configure. if we look at the log, we see: checking for limits.h... checking for memory.h... Terminated that cant be good. grepping for "Terminated" in the log shows many more hits. something is screwed on your system. look at `dmesg` to see if you're running out of memory or something.
(In reply to comment #7) > limits.h isnt being included in your fibheap build. this is because it isnt > being detected by configure. > > if we look at the log, we see: > checking for limits.h... checking for memory.h... Terminated > > that cant be good. grepping for "Terminated" in the log shows many more hits. > something is screwed on your system. look at `dmesg` to see if you're running > out of memory or something. > Well, I did have a memory-hungry process running for a messed up rbot instance a day ago and because I had it set up with the initscripts, it ended up restarting. I don't ever see any OOM killer being woken up in my dmesg, but this is probably the problem. However, I'm more concerned about some ``Hangcheck: hangcheck value past margin!'' dmesgs which I think are pointing to some problem with my reiserfs partitions, but I'm convinced that this dmesg is unrelated to gcc being Terminated. Thanks for debugging this for me and sorry for not noticing the ``Terminated'' lines in my build.log which point to problems in my system.
