Created attachment 316571 [details] emerge --info I upgraded from gcc-4.7.0 to gcc-4.7.1. (Note, I realize gcc-4.7.x is masked... but I figure a bug that makes the whole system unrunnable without recompiling a thing is important enough to mention...I kept the priority "normal" for just that reason, that these are masked.) (Unfortunately I didn't keep a log, but...) in the ebuild, gcc-4.7.1 was successfully built. It was successfully installed into /usr/lib/gcc/i686-pc-linux-gnu/4.7.1. I think my problems began right when 4.7.0 was removed.. anyway at the end of the emerge I had some pages of errors saying emerge had failed and such. Running ANY binary resulted in errors such as: ls: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory Luckily I had the root NFS exported so I could look around and see what happened! 8-) Anyway, on the first machine I made a symlink via NFS. On the second.. well, here's a workaround that *doesn't* require that, since luckily gentoo does include one or two *statically linked* utilities just for this eventuality...: cd /usr/lib/gcc/i686-pc-linux-gnu/ sln 4.7.1 4.7.0 At this point, your programs are working. But leaving a phantom symlink there isn't a great idea IMHO. So... gcc-config -l (This will list all GCC configs... pick the one that is for 4.7.1. In my case, "gcc-config 2"). source /etc/profile You can then safely "rm 4.7.0" I assume the ebuild just needs a tweak.
More than likely this is some filesystem anamoly and has nothing to do with gcc 4.7.1, but it just so happens that was what was building when it happened. Many people (including myself have compiled gcc 4.7.1 and not had the system break). Not having any logs/info available isn't going to help anyone find out what happened, especially if no one else is able to repeat it. I've build 4.7.1 and indeed rebuild my system with 4.7.1 and haven't had this issue. The differenences between 4.7.0 and 4.7.0 are relatively minor (mostly bug fixes). The differences in the ebuilds are trivial.
Well, I don't know, I ran this on two different systems (the other is -march=athlon-xp instead of -march=k8-sse3 but otherwise set up just about identically). Well, here's what I found in the log: 1340866294: *** emerge --oneshot --quiet-build=n gcc 1340866343: >>> emerge (1 of 1) sys-devel/gcc-4.7.1 to / 1340866344: === (1 of 1) Cleaning (sys-devel/gcc-4.7.1::/mnt/delta/usr/portage/ sys-devel/gcc/gcc-4.7.1.ebuild) 1340866447: === (1 of 1) Compiling/Merging (sys-devel/gcc-4.7.1::/mnt/delta/usr /portage/sys-devel/gcc/gcc-4.7.1.ebuild) 1340876436: === (1 of 1) Merging (sys-devel/gcc-4.7.1::/mnt/delta/usr/portage/s ys-devel/gcc/gcc-4.7.1.ebuild) 1340876452: >>> AUTOCLEAN: sys-devel/gcc:4.7 1340876452: === Unmerging... (sys-devel/gcc-4.7.0) 1340876457: >>> unmerge success: sys-devel/gcc-4.7.0 1340876459: === (1 of 1) Post-Build Cleaning (sys-devel/gcc-4.7.1::/mnt/delta/u sr/portage/sys-devel/gcc/gcc-4.7.1.ebuild) 1340876459: ::: completed emerge (1 of 1) sys-devel/gcc-4.7.1 to / 1340876460: *** Finished. Cleaning up... 1340876466: *** exiting successfully. 1340876467: *** terminating. I wish I had captured the errors, but I think the errors were actually after gcc-4.7.0 was removed, it didn't show any useful information, it was one of the portage errors that an unexpected error occured and to check your RAM and la-de-da, about 20 times in a row. Ahh..here it is in the portage code: "The ebuild phase '%s' has exited unexpectedly. This type of behavior is known to be triggered by things such as failed variable assignments (bug #190128) or bad substitution errors (bug #200313). Normally, before exiting, bash should have displayed an error message above. If bash did not produce an error message above, it's possible that the ebuild has called `exit` when it should have called `die` instead. This behavior may also be triggered by a corrupt bash binary or a hardware problem such as memory or cpu malfunction. If the problem is not reproducible or it appears to occur randomly, then it is likely to be triggered by a hardware problem. If you suspect a hardware problem then you should try some basic hardware diagnostics such as memtest. Please do not report this as a bug unless it is consistently reproducible and you are sure that your bash binary and hardware are functioning properly." I do see /etc/ld.so.conf.d/05gcc-i686-pc-linux-gnu.conf has the expected contents. I wonder if I could have just run ldconfig, or rebooted? At any rate, if nobody else is having the problem that's fine by me. And if they do, and ldconfig doesn't do it, there's the procedure ----^ (in post 1) for getting out of it. Feel free to close the bug out -- personally, I'd leave it open a few days in case of "me toos" but either way works for me.
i'm guessing this is because of your compiler flags which implicitly induce linking to internal gcc libraries. probably same concept as Bug 189634. i imagine if you stopped using "-floop-block -floop-interchange -floop-strip-mine" on all the packages in your system (and rebuilt them), this wouldn't break. launch a root shell and try running: mv /etc/ld.so.conf.d/05gcc-i686-pc-linux-gnu.conf ~/ ldconfig emerge --info mv ~/05gcc-i686-pc-linux-gnu.conf /etc/ld.so.conf.d/ ldconfig see if that emerge fails, and if so, what is the error. also post the output of running: ldd /usr/lib/libpython*.so
