Updating gcc from 4.7.1 to 4.7.2 kills the system: --- >>> Installing (1 of 1) sys-devel/gcc-4.7.2 [sys-devel/gcc-4.7.1] bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory * The ebuild phase 'postrm' 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. /bin/bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory * The ebuild phase 'die_hooks' 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. !!! FAILED postrm: 1 * The 'postrm' phase of the 'sys-devel/gcc-4.7.1' package has failed with * exit value 1. * * The problem occurred while executing the ebuild file named * 'gcc-4.7.1.ebuild' located in the '/var/db/pkg/sys-devel/gcc-4.7.1' * directory. If necessary, manually remove the environment.bz2 file and/or * the ebuild file located in that directory. * * Removal of the environment.bz2 file is preferred since it may allow the * removal phases to execute successfully. The ebuild will be sourced and * the eclasses from the current portage tree will be used when necessary. * Removal of the ebuild file will cause the pkg_prerm() and pkg_postrm() * removal phases to be skipped entirely. sh: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory [sys-devel/gcc-4.7.2] bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory * The ebuild phase 'postinst' 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. /bin/bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory * The ebuild phase 'die_hooks' 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. !!! FAILED postinst: 1 /bin/bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory * The ebuild phase 'other' 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. [sys-devel/gcc-4.7.2] bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory /bin/bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory * The ebuild phase 'die_hooks' 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. * Messages for package sys-devel/gcc-4.7.1: * The ebuild phase 'postrm' 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. * The 'postrm' phase of the 'sys-devel/gcc-4.7.1' package has failed with * exit value 1. * * The problem occurred while executing the ebuild file named * 'gcc-4.7.1.ebuild' located in the '/var/db/pkg/sys-devel/gcc-4.7.1' * directory. If necessary, manually remove the environment.bz2 file and/or * the ebuild file located in that directory. * * Removal of the environment.bz2 file is preferred since it may allow the * removal phases to execute successfully. The ebuild will be sourced and * the eclasses from the current portage tree will be used when necessary. * Removal of the ebuild file will cause the pkg_prerm() and pkg_postrm() * removal phases to be skipped entirely. * Messages for package sys-devel/gcc-4.7.2: * * LTO support is still experimental and unstable. * Any bugs resulting from the use of LTO will not be fixed. * * The ebuild phase 'postinst' 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. * The ebuild phase 'other' 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. >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date. sh: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory sh: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory sh: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory * IMPORTANT: 11 news items need reading for repository 'gentoo'. * Use eselect news to read news items. --- Afterwards the whole system is broken. Fix is: 1. boot another system 2. mount broken system 3. fix path to gcc in /etc/ld.so.conf.d (from 4.7.1 to 4.7.2) (4.fix paths to gcc in /etc/env.d) 5. run ldconfig -r /somewhere/mounted_system 6. try chrooting into fixed system and call env-update This happened here on 2 armv5 systems. One had gcc-config-1.6, another had gcc-config-1.7.3. I haven't looked at the ebuild for gcc 4.7.2, but I would assume that the old libgcc_s.so.1 from 4.7.1 got deleted before the linker knew about the new one from 4.7.2. (I haven't experienced that problem on my x86_64-box when I've updated there from 4.7.1 to 4.7.2, but that just might have been luck) Reproducible: Always
This seems neither related with arm nor with a particular gcc version (I can and could reproduce it on amd64 and x86 with several gcc versions) unless you compile a lot of progams with USE=static. I was very surprised that this is the first report on the issue that I see; maybe the problem does not occur if one does not set LD_BIND_NOW and if one do not use -Wl,z,now (both I never tried for security reasons). The problem occurs (at least with LD_BIND_NOW) reproducable if the slot of the running compiler version is upgraded: In this case, portage removes the old compiler and then calls gcc-config to configure the new. Unfortunately, gcc-config fails after the removal because programs like "ln" break since they are linked against libgcc_s.so.1 which is no longer in the library path of the old gcc (since that was removed). A manual workaround is to use busybox to create in /usr/lib/gcc/$ARCH a symlink from the old compiler version to the new and then call gcc-config. Afterwards the symlink can be removed. It might also be possible to call gcc-config from bb; I have not tried this yet and made no research whether bb is available in all systems. If this is the case, maybe a proper fix is making gcc-config a #!/bin/bb binary (and if necessary making compatibility changes in that code). Another fix might be to make gcc-config a statically linked binary (which should not be that hard to do...). Yet another fix might be to call gcc-config before portage removes the old compiler - I do not know whether this is possible.
*** This bug has been marked as a duplicate of bug 433161 ***