Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 437050 - gcc-4.7.2: updating from 4.7.1 kills system (ARM)
Summary: gcc-4.7.2: updating from 4.7.1 kills system (ARM)
Status: RESOLVED DUPLICATE of bug 433161
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: ARM Linux
: Normal critical (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-03 08:58 UTC by Alexander Holler
Modified: 2012-10-03 19:06 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Holler 2012-10-03 08:58:57 UTC
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
Comment 1 Martin Väth 2012-10-03 10:24:52 UTC
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.
Comment 2 SpanKY gentoo-dev 2012-10-03 19:06:05 UTC

*** This bug has been marked as a duplicate of bug 433161 ***