I get the following error when trying to emerge mysql: ==================================================== x86_64-pc-linux-gnu-g++: Internal error: Killed (program cc1plus) Please submit a full bug report. See <URL:http://bugs.gentoo.org/> for instructions. {standard input}: Assembler messages: {standard input}:116584: Warning: end of file not at end of a line; newline inserted make[4]: *** [sql_yacc.o] Error 1 make[4]: *** Waiting for unfinished jobs.... make[4]: Leaving directory `/var/tmp/portage/mysql-5.0.18-r30/work/mysql/sql' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/var/tmp/portage/mysql-5.0.18-r30/work/mysql/sql' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/portage/mysql-5.0.18-r30/work/mysql/sql' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/mysql-5.0.18-r30/work/mysql' make: *** [all] Error 2 !!! ERROR: dev-db/mysql-5.0.18-r30 failed. !!! Function mysql_src_compile, Line 378, Exitcode 2 !!! compile problem !!! If you need support, post the topmost build error, NOT this status message. ==================================================== What should I do about this?
Most likely out of memory/disk space, bad RAM or other hardware problem. *** This bug has been marked as a duplicate of 20600 ***
"out of memory" was it. Thanks! This is then a feature request, not a bug (although the current error message could be thought of as "buggy"): Any chance that the error message could be changed from: ================== Internal error: Killed (program cc1plus) Please submit a full bug report. See <URL:http://bugs.gentoo.org/> for instructions. ================== To something like: ================== Internal error: Killed (program blah) Most likely you're running out of memory or have bad RAM. See <wiki link> for more information. ================== ? Changing the error message to something slightly more helpful would allow dumb people like me to use Portage without pestering bright people like you all the time..
there are a ton more things that could be and i doubt upstream would be willing to change the message, sorry :/
Ok, sorry for being persistent and reopening, but can we give it just a little more thought? Here's an idea; how about we tee the output of the build process into a FIFO buffer of some sort; and when the build process dies, we can grep the last 2kB for the problematic error message. If it occurs, we can add something like this in red / yellow types: * Seems compilation failed because a program was killed. Normally this occurs because you've run out of RAM. See the wiki at <...> for more {suggestions,information}.
this isnt really for us to do, this is something for the gcc peeps to update, and i'm pretty sure they wouldnt go for this
Ok, so the facts in a pragmatic dimension is: 1.) We seem to all know that the GCC peeps is not magically going to make things the way we need them. Absolutely no hope. 2.) There's an easy way to fix this on our side. And the technical facts are: A.) Technically, looking at things from the GCC side of the fence, the error message *is* correct. B.) Looking at it from a Portage user's POV, the error message is horribly incorrect, because Portage is meant to be user friendly. == From A) and B) we can derive that the right place to fix this *is* really Portage. (From 1) and 2) we can derive that in the real world, the only place this is ever plausible to fix *is* in Portage.) So let's get on with the thinking instead of just throwing our hands in the air and giving up? By the way, is there a mailing list for this kind of discussions? Battling two people over a 'WONTFIX/REOPENED' flag seems moot..
> 2.) There's an easy way to fix this on our side. i dont think so > B.) Looking at it from a Portage user's POV, the error message is horribly > incorrect, because Portage is meant to be user friendly. there is no real way to know why the program was killed maybe you were out of free ram maybe you were out of disk space maybe the binary is miscompiled and randomly crashes maybe there is an error in the program and it keeps crashing maybe a kernel bug felt that the program was doing something wrong and killed it maybe the kernel is miscompiled and it randomly kills programs maybe a hardware error prompted the kernel to kill it listing all the random possibilities doesnt gain anything > By the way, is there a mailing list for this kind of discussions? > Battling two people over a 'WONTFIX/REOPENED' flag seems moot.. gentoo-dev mailing list
>> 2.) There's an easy way to fix this on our side. > i dont think so Hmm, what was wrong with my proposal? > there is no real way to know why the program was killed > [snip options] True, but 95/100 you're low on RAM, 5/100 some hardware is defect which can be checked with memtest86. > listing all the random possibilities doesnt gain anything Sure it does, it improves user friendliness by ALOT !! Especially if you tell: * What's the most likely thing (what to check first) * How to proceed (increase RAM, run memtest86) > gentoo-dev mailing list Super, thanks a lot! I'll take it there (you agree that's the proper place right?) I won't mind if you deassign toolchain and reassign to ?? portage or whatever, or set to CANTFIX for toolchain :) (I don't think this has much to do with GCC/LD/etc specifically.)
Not a bug. I also don't see how it helps to give a list of possible problems, all of which are just as plausible as the next. It is going to be just as confusing, just in a whole new way.
> Not a bug. Yeah, in the exact same way it isn't a bug in pre-2000 versions of Windows that you had to restart when you changed the IP address. > I also don't see how it helps to give a list of possible problems, > all of which are just as plausible as the next. 95% probability: too little free RAM 5% probability: bad RAM or other hardware (run memtest) 0.00000001% probability: the rest. None of them are "just as plausible as the next". > It is going to be just as confusing, just in a whole new way. Nah...
(In reply to comment #10) > 95% probability: too little free RAM > 5% probability: bad RAM or other hardware (run memtest) > 0.00000001% probability: the rest. Please don't keep stating these invented statistics. It's simply just not true to say that "killed => out of memory". Look at the list of possibilities that SpanKY gave you in comment #7. Having said that, if mysql is unusually demanding w.r.t memory/disk usage, perhaps it could make use of the check-reqs.eclass. Re-opening to reassign.
mysql people - if mysql demands significant resources to build (>256M RAM, >1GB temporary disk space), can you consider using check-req.eclass? If not, mark as dup of bug #20600. P.S. and can you fix your metadata.xml to indicate mysql-bugs@g.o as maintainer since the herd doesn't have an alias on bugzilla?
> Please don't keep stating these invented statistics. Why not? Can you honestly say that you don't believe those "statistics" are true? And besides, all that those "statistics" would be used to (if my proposal was implemented) would be to order the various solutions on the wiki. You would be free to add all that weird crap that never happens that you keep talking about :-).
(In reply to comment #12) > mysql people - if mysql demands significant resources to build (>256M RAM, >1GB > temporary disk space), can you consider using check-req.eclass? > > If not, mark as dup of bug #20600. indeed > > P.S. and can you fix your metadata.xml to indicate mysql-bugs@g.o as maintainer > since the herd doesn't have an alias on bugzilla? > Done, sorry for the delay *** This bug has been marked as a duplicate of 20600 ***
*** Bug 126797 has been marked as a duplicate of this bug. ***
