Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
auto delete of libgcc_s.so.1 :-(
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
darklegion
Guru
Guru


Joined: 14 Nov 2004
Posts: 468

PostPosted: Wed Jun 05, 2013 4:12 am    Post subject: Reply with quote

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
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Thu Jun 06, 2013 12:38 pm    Post subject: Reply with quote

This is still going on? Has anyone filed a bug yet?
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Fri Sep 06, 2013 3:05 pm    Post subject: There is a Bug! ;) Reply with quote

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
View user's profile Send private message
shimbob
Tux's lil' helper
Tux's lil' helper


Joined: 13 Sep 2003
Posts: 134

PostPosted: Wed Nov 20, 2013 8:48 pm    Post subject: Reply with quote

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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Wed Nov 20, 2013 9:51 pm    Post subject: Reply with quote

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
View user's profile Send private message
SMOKEING
n00b
n00b


Joined: 07 Jan 2009
Posts: 5

PostPosted: Wed Nov 20, 2013 10:57 pm    Post subject: Reply with quote

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
View user's profile Send private message
Jaglover
Watchman
Watchman


Joined: 29 May 2005
Posts: 8291
Location: Saint Amant, Acadiana

PostPosted: Fri Nov 22, 2013 12:59 am    Post subject: Reply with quote

I just got bitten by this, thanks everybody for posting their solutions. :)
_________________
My Gentoo installation notes.
Please learn how to denote units correctly!
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Fri Nov 22, 2013 4:14 am    Post subject: Reply with quote

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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Fri Nov 22, 2013 8:27 am    Post subject: Reply with quote

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
View user's profile Send private message
Jaglover
Watchman
Watchman


Joined: 29 May 2005
Posts: 8291
Location: Saint Amant, Acadiana

PostPosted: Sat Nov 23, 2013 1:16 am    Post subject: Reply with quote

Well, I had 4.8 installed and enabled. It was upgrade to r1 or something that borked it. After running ldconfig there was no active compiler left, although I do have also 4.7 installed.
_________________
My Gentoo installation notes.
Please learn how to denote units correctly!
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sat Nov 23, 2013 2:49 am    Post subject: Reply with quote

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
View user's profile Send private message
Jaglover
Watchman
Watchman


Joined: 29 May 2005
Posts: 8291
Location: Saint Amant, Acadiana

PostPosted: Sat Nov 23, 2013 3:23 am    Post subject: Reply with quote

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
View user's profile Send private message
wswartzendruber
Veteran
Veteran


Joined: 23 Mar 2004
Posts: 1261
Location: Idaho, USA

PostPosted: Thu May 22, 2014 6:40 am    Post subject: Reply with quote

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
View user's profile Send private message
f.kater
Guru
Guru


Joined: 23 May 2002
Posts: 342
Location: Berlin

PostPosted: Wed Aug 20, 2014 10:55 am    Post subject: Reply with quote

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
View user's profile Send private message
darklegion
Guru
Guru


Joined: 14 Nov 2004
Posts: 468

PostPosted: Sun Sep 07, 2014 10:53 am    Post subject: Reply with quote

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
View user's profile Send private message
ShiroiKuma
n00b
n00b


Joined: 09 Nov 2012
Posts: 40
Location: Japan

PostPosted: Wed Oct 29, 2014 11:29 am    Post subject: Reply with quote

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
View user's profile Send private message
destroyedlolo
l33t
l33t


Joined: 17 Jun 2011
Posts: 846
Location: Close to Annecy (France)

PostPosted: Wed Nov 26, 2014 9:52 pm    Post subject: Reply with quote

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
View user's profile Send private message
netfab
Veteran
Veteran


Joined: 03 Mar 2005
Posts: 1887
Location: 127.0.0.1

PostPosted: Thu Dec 04, 2014 1:24 pm    Post subject: Reply with quote

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
View user's profile Send private message
jmbsvicetto
Moderator
Moderator


Joined: 27 Apr 2005
Posts: 4734
Location: Angra do Heroísmo (PT)

PostPosted: Fri May 08, 2015 10:41 am    Post subject: Reply with quote

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:

    4.6.4
    4.7.3
    4.8.3
    4.9.2

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum