View previous topic :: View next topic |
Author |
Message |
darklegion Guru
Joined: 14 Nov 2004 Posts: 468
|
Posted: Wed Jun 05, 2013 4:12 am Post subject: |
|
|
This has happened on three different systems to me for the gcc-4.7.2 to 4.7.3 upgrade. I just used systemrescuecd to copy /usr/lib/gcc/<arch>/4.7.3 to /usr/lib/gcc/<arch>/4.7.2 and that was enough to run gcc-config and fix the issue. Then I could remove the 4.7.2 directory. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Thu Jun 06, 2013 12:38 pm Post subject: |
|
|
This is still going on? Has anyone filed a bug yet? |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Fri Sep 06, 2013 3:05 pm Post subject: There is a Bug! ;) |
|
|
Well this came up in #-embedded when some mentioned bug 433161 so just putting it here for reference (and bumping the post, which is why I didn't just edit the last one.) It seems to be still getting dupes, and aholler mentioned that he's still using his patch for toolchain.eclass.
It sounded like (there is also) a bug in gcc-config from gpiez's comment in January:
gpiez wrote: | the culprit was in line 321-330 in gcc-config, where libgcc_s.so in /lib just gets deleted, while the path to the current libgcc_s.so is no longer valid because of the compiler slot update. |
That sounds a lot like the topic of this post. |
|
Back to top |
|
|
shimbob Tux's lil' helper
Joined: 13 Sep 2003 Posts: 136
|
Posted: Wed Nov 20, 2013 8:48 pm Post subject: |
|
|
Just got bit by this bug when my machine upgraded to GCC 4.8.2 (I know, it's hardmasked, going to figure out why emerge included it).
My solution was to boot with a liveCD, mounted / and other bits, then since I couldn't do a simple chroot as /bin/bash depended on libgcc I tried "chroot . ldconfig" and that rebuild the ld.so.cache file. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Wed Nov 20, 2013 9:51 pm Post subject: |
|
|
The bug still happens at every gcc upgrade on amd64 and x86 (and probably other arches, too). This just hit me when uprading a remote machine which - by accident - lost ssh connection with the effect that I could not login remote anymore to repair the issue.
Although a patch with the fix is attached to the bug for more than 1 year, such a show-stopper is still not fixed!
It really is a shame. |
|
Back to top |
|
|
SMOKEING n00b
Joined: 07 Jan 2009 Posts: 5
|
Posted: Wed Nov 20, 2013 10:57 pm Post subject: |
|
|
Just my $.02 of yet another case of this borkage happening. This scared a pound of shit out of me, and reminded me once more why a statically linked busybox is so essential on Gentoo. |
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Fri Nov 22, 2013 4:14 am Post subject: |
|
|
mv wrote: | The bug still happens at every gcc upgrade on amd64 and x86 (and probably other arches, too). This just hit me when uprading a remote machine which - by accident - lost ssh connection with the effect that I could not login remote anymore to repair the issue.
Although a patch with the fix is attached to the bug for more than 1 year, such a show-stopper is still not fixed!
It really is a shame. |
I'm quite amazed this hasn't been fixed already as well. I've been offline for a bit, but will be working on update -- toolchain soon; for the first time I can remember gcc didn't upgrade correctly. Nothing major, just didn't change to the new version, which used to be a done thing.
There was a warning message about it not changing since it was a slot upgrade, though my code is supposed to do it, which is the bug; but it means I have to add something to check which version of gcc was used to build stuff, which is where I am atm (or was before my machine went down.) Previously I've just been checking whether it was built after the compiler was installed, which doesn't work for this case (we'd gone ahead and built stuff, thinking the compiler was upgraded, so a user might do something similar) and is not robust.
Wondering if that was in response to this bug, though I don't recall such a message before, and I wasn't aware they'd started switching in the ebuild. In any event, is the patch working properly for you? If so we've got more grounds for pushing for a resolution. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Fri Nov 22, 2013 8:27 am Post subject: |
|
|
steveL wrote: | In any event, is the patch working properly for you? |
I haven't tested, and testing now after the upgrade would take rather long. However, the patch looks like it might solve the issue.
Quote: | There was a warning message about it not changing since it was a slot upgrade |
For slot upgrades (e.g. 4.7->4.8, or are you using USE=multislot?) the gcc version never was changed. Since in this case the old gcc version is kept, the issue never occurs - it is the unmerging of the old version (when the new one is not yet initialized with gcc-config) which causes grief. I bet that the gcc developers use multisllot (otherwise they might remain with a broken gcc for every local testing upgrade they do); this is the reason why the bug does not hit them. |
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sat Nov 23, 2013 2:49 am Post subject: |
|
|
mv wrote: | Quote: | There was a warning message about it not changing since it was a slot upgrade |
For slot upgrades (e.g. 4.7->4.8, or are you using USE=multislot?) the gcc version never was changed. Since in this case the old gcc version is kept, the issue never occurs - it is the unmerging of the old version (when the new one is not yet initialized with gcc-config) which causes grief. |
I'd never seen the ebuild itself try to run gcc-config, which is why update has had code to deal with that situation for several years. For some reason it didn't kick in: I have a feeling that it's to do with --jobs, but I'd tested that before, and I don't recall an error message from update. So that is next in the queue, after the binary check of gcc version in --toolchain.
Quote: | I bet that the gcc developers use multislot (otherwise they might remain with a broken gcc for every local testing upgrade they do); this is the reason why the bug does not hit them. |
Well jaglover hit it too with 4.8 minor upgrade, so clearly it's just the new ebuild check, wherever that is, which is broken. As you said the patch should fix it: in any event we should not remove the old version, until the new one has been successfully set with gcc-config. For portage that requires a has_version ofc, though this does indicate again why plumbing and porcelain is a useful distinction.
@jaglover: does the patch fix it for you with 4.8 upgrade? |
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
Posted: Sat Nov 23, 2013 3:23 am Post subject: |
|
|
Hmm, here is the sequence:
I had 4.7 and 4.8 installed in this box, 4.8 active;
while upgrading @world 4.8 had a minor upgrade;
I wasn't watching it, but next time I looked at it it had that threaded "error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory" and the whole system was totally unusable, reboot failed, too;
I booted from USB and ran ldconfig, which allowed the system to boot in it's own but no gcc was enabled;
another @world upgrade ran without errors, so there is nothing to patch at the moment ... _________________ My Gentoo installation notes.
Please learn how to denote units correctly! |
|
Back to top |
|
|
wswartzendruber Veteran
Joined: 23 Mar 2004 Posts: 1261 Location: Idaho, USA
|
Posted: Thu May 22, 2014 6:40 am Post subject: |
|
|
I just updated my DreamPlug (~arm) to GCC 4.8 and got hit by this. ldconfig seems to have fixed things, though. |
|
Back to top |
|
|
f.kater Guru
Joined: 23 May 2002 Posts: 342 Location: Berlin
|
Posted: Wed Aug 20, 2014 10:55 am Post subject: |
|
|
FYI: This bug is still present here on several gentoo boxes. Annoying
especially in cases where I update GCC on a VM in a detached screen session...
Then there is no recovery at all since reboot fails.
If not mentioned elsewhere already: The GCC update fails only in case the
*currently used* GCC is tried to be updated (replaced) by a newer version.
Extra notes: With gentoo having a rolling versioning system I haven't freshly
reinstalled my box for years (and all others are clones), only updated, so the
reason why we all are hit might be somewhat older.
These are always the last lines when the bug happens (I am using paludis/cave,
not emerge):
Code: |
<<< /usr/bin/gfortran-4.8.2
<<< /usr/bin/gcov-4.8.2
<<< /usr/bin/gcc-4.8.2
<<< /usr/bin/g++-4.8.2
<<< /usr/bin/cpp-4.8.2
<<< /usr/bin/c++-4.8.2
--- [ignor] /usr/bin
--- [ignor] /usr
--- [!md5 ] /etc/env.d/gcc/x86_64-pc-linux-gnu-4.8.2
--- [ignor] /etc/env.d/gcc
--- [ignor] /etc/env.d
--- [ignor] /etc
Failed install to / for sys-devel/gcc-4.8.3:4.8::gentoo replacing
4.8.2-r1:4.8::installed
bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared
object file: No such file or directory
cave@1408019848: [WARNING hook.bash.failure] Hook
'/usr/libexec/paludis/hooks/install_all_post/gnu_info_index.bash' returned
failure '127'
bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared
object file: No such file or directory
cave@1408019848: [WARNING hook.bash.failure] Hook
'/usr/libexec/paludis/hooks/install_all_post/log.bash' returned failure '127'
|
|
|
Back to top |
|
|
darklegion Guru
Joined: 14 Nov 2004 Posts: 468
|
Posted: Sun Sep 07, 2014 10:53 am Post subject: |
|
|
Had the problem again as well. I had to use a liveusb as I was using sudo for the emerge and couldn't gain root access. Hopefully this will be fixed soon as it's a pretty severe bug. |
|
Back to top |
|
|
ShiroiKuma n00b
Joined: 09 Nov 2012 Posts: 40 Location: Japan
|
Posted: Wed Oct 29, 2014 11:29 am Post subject: |
|
|
Just hosed my own system by doing an emerge --depclean before updating my gcc-config to point to the newest version.
@turtle's post saved my RPi system, thanks! That's a nice little bit of code! |
|
Back to top |
|
|
destroyedlolo l33t
Joined: 17 Jun 2011 Posts: 846 Location: Close to Annecy (France)
|
Posted: Wed Nov 26, 2014 9:52 pm Post subject: |
|
|
I faced this issue as well while upgrading one of my ARM box from 4.7.3 to 4.8.3.
It seems it was triggered when I did emerge --depclean : it removed 4.7.3 without having ldconfig updated (even if I did gcc-config switch before).
Fortunately, I discovered the problem before rebooting and I can solve (I hope) it by doing :
Code: | LD_LIBRARY_PATH=/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.8.3/ ldconfig |
|
|
Back to top |
|
|
netfab Veteran
Joined: 03 Mar 2005 Posts: 1897 Location: 127.0.0.1
|
Posted: Thu Dec 04, 2014 1:24 pm Post subject: |
|
|
destroyedlolo wrote: | I faced this issue as well while upgrading one of my ARM box from 4.7.3 to 4.8.3.
It seems it was triggered when I did emerge --depclean : it removed 4.7.3 without having ldconfig updated (even if I did gcc-config switch before).
Fortunately, I discovered the problem before rebooting and I can solve (I hope) it by doing :
Code: | LD_LIBRARY_PATH=/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.8.3/ ldconfig |
|
Exactly the same behavior (and solution) here on my armv7 box. |
|
Back to top |
|
|
jmbsvicetto Moderator
Joined: 27 Apr 2005 Posts: 4734 Location: Angra do Heroísmo (PT)
|
Posted: Fri May 08, 2015 10:41 am Post subject: |
|
|
netfab wrote: | destroyedlolo wrote: | I faced this issue as well while upgrading one of my ARM box from 4.7.3 to 4.8.3.
It seems it was triggered when I did emerge --depclean : it removed 4.7.3 without having ldconfig updated (even if I did gcc-config switch before).
Fortunately, I discovered the problem before rebooting and I can solve (I hope) it by doing :
Code: | LD_LIBRARY_PATH=/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.8.3/ ldconfig |
|
Exactly the same behavior (and solution) here on my armv7 box. |
I've just hit the same issue on my odroid-u2. Although in my case I had the following gcc versions installed:
I started my update by switching gcc active version to 4.9.2. I then removed 4.6.4 and 4.8.3 with --depclean. When I updated gcc 4.7.3 to 4.7.4, I got into this mess.
Code: |
$ sudo gcc-config -l
$ sudo gcc-config 16
$ sudo env-update
$ source /etc/profile
$ sudo emerge --depclean =gcc-4.6.4
$ sudo emerge --depclean =gcc-4.8.3
$ sudo emerge -uDavN1 --quiet-build=y --keep-going=y linux-headers glibc gcc binutils gcc-config binutils-config
|
I've used the same method presented in this thread. I just want to leave a brief note for anyone sitting with an open ssh connection without sudo / root access, that one can use busybox to help rescue the system:
Code: |
$ /bin/bb
$ /bin/su -s /bin/bb
# LD_LIBRARY_PATH=/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.9.2 ldconfig
#
|
_________________ Jorge.
Your twisted, but hopefully friendly daemon.
AMD64 / x86 / Sparc Gentoo
Help answer || emwrap.sh
|
|
Back to top |
|
|
|