Perhaps another out-of-memory problem (64 megs + 128 megs swap on this box)? During emerge kde the machine was mostly frozen (would take the Return key, but couldn't log in to another tty, couldn't do a ctrl-C, and the mouse was lost) at the step of "creating libnoatcontrols.la", with a warning about a deprecated header, strstream.h, following that. After reboot "emerge kde --pretend" shows kdemultimedia as the first dependency listed, which means that was the problem package, right? If the fix here is to lessen the degree of optimization, I don't know enough about that. Perhaps list of optimization flags, in the order in which they should be removed from ebuilds in problem cases, would be useful to have - at least if the statement that Gentoo can be built in 64 megs + 64 megs swap is going to stay in the main install doc. Although I sometimes build servers without a GUI, for most of the world it's not a distro without one ;>
try running memtest86/cpuburn ?
please edit the kdemultimedia ebuild to have no "--enable-final" and emerge it again.
No errors from memtest86 (3.0) or cpuburn. kdemultimedia-3.0.4.ebuild does not have an --enable-final statement.
kdemultimedia uses an eclass (kde-dist.eclass). please remove the line myconf="$myconf --enable-final" from /usr/portage/eclass/kde-dist.eclass
Removing --enable-final did produce what is probably a successful KDE build. Perhaps ebuilds should as a rule grep /proc/meminfo and only use --enable-final if there is enough free memory on the system to handle the particular package? Note I say "probably successful" because the XFree install somehow came out really screwed up, so I haven't been able to verify that KDE will actually run. I've submitted a new bug on that.
We now check /proc/meminfo and only enable --enable-final if >=200MB free ram+swap is available. (If it's enabled where it shouldn't be for you, tell us.)
