On my arm server, "emerge -uDN world" installed gcc-4.5.4, gcc-4.5.3 was "autocleaned" but no change was made to /etc/ld.so.conf (or more accurately /etc/ld.so.conf.d/*gcc*), so after that even /bin/bash could not be executed (surprisingly "ldd /bin/bash" on the arm box states that it needs libgcc_s.so.1, while it does not need it on my amd64 box). I had to hexedit /etc/ld.so.cache (using another computer) to replace 4.5.3 by 4.5.4 when needed, because I did not know of any other way to regenerate the cache. Portage version is 2.1.11.9. Below is emerge.log, although it is not very instructive: Started emerge on: Aug 28, 2012 18:16:37 *** emerge --newuse --deep --keep-going --update --quiet world >>> emerge (1 of 9) sys-libs/glibc-2.15-r2 to / === (1 of 9) Cleaning (sys-libs/glibc-2.15-r2::/usr/portage/sys-libs/glibc/glibc-2.15-r2.ebuild) === (1 of 9) Compiling/Merging (sys-libs/glibc-2.15-r2::/usr/portage/sys-libs/glibc/glibc-2.15-r2.ebuild) >>> emerge (1 of 8) net-libs/libnatpmp-20120821 to / === (1 of 8) Cleaning (net-libs/libnatpmp-20120821::/usr/portage/net-libs/libnatpmp/libnatpmp-20120821.ebuild) === (1 of 8) Compiling/Merging (net-libs/libnatpmp-20120821::/usr/portage/net-libs/libnatpmp/libnatpmp-20120821.ebuild) === (1 of 8) Merging (net-libs/libnatpmp-20120821::/usr/portage/net-libs/libnatpmp/libnatpmp-20120821.ebuild) >>> AUTOCLEAN: net-libs/libnatpmp:0 === Unmerging... (net-libs/libnatpmp-20110808-r1) >>> unmerge success: net-libs/libnatpmp-20110808-r1 === (1 of 8) Post-Build Cleaning (net-libs/libnatpmp-20120821::/usr/portage/net-libs/libnatpmp/libnatpmp-20120821.ebuild) ::: completed emerge (1 of 8) net-libs/libnatpmp-20120821 to / >>> emerge (2 of 8) sys-devel/gcc-4.5.4 to / === (2 of 8) Cleaning (sys-devel/gcc-4.5.4::/usr/portage/sys-devel/gcc/gcc-4.5.4.ebuild) === (2 of 8) Compiling/Merging (sys-devel/gcc-4.5.4::/usr/portage/sys-devel/gcc/gcc-4.5.4.ebuild) === (2 of 8) Merging (sys-devel/gcc-4.5.4::/usr/portage/sys-devel/gcc/gcc-4.5.4.ebuild) >>> AUTOCLEAN: sys-devel/gcc:4.5 === Unmerging... (sys-devel/gcc-4.5.3-r2) >>> unmerge success: sys-devel/gcc-4.5.3-r2 === (2 of 8) Post-Build Cleaning (sys-devel/gcc-4.5.4::/usr/portage/sys-devel/gcc/gcc-4.5.4.ebuild) ::: completed emerge (2 of 8) sys-devel/gcc-4.5.4 to / >>> emerge (3 of 8) sys-apps/busybox-1.20.2 to / === (3 of 8) Cleaning (sys-apps/busybox-1.20.2::/usr/portage/sys-apps/busybox/busybox-1.20.2.ebuild) >>> emerge (1 of 5) net-libs/libpcap-1.1.1-r1 to / === (1 of 5) Cleaning (net-libs/libpcap-1.1.1-r1::/usr/portage/net-libs/libpcap/libpcap-1.1.1-r1.ebuild) >>> emerge (1 of 4) dev-libs/libevent-2.0.20 to / === (1 of 4) Cleaning (dev-libs/libevent-2.0.20::/usr/portage/dev-libs/libevent/libevent-2.0.20.ebuild) >>> emerge (1 of 3) net-analyzer/net-snmp-5.7.2_rc1 to / === (1 of 3) Cleaning (net-analyzer/net-snmp-5.7.2_rc1::/usr/portage/net-analyzer/net-snmp/net-snmp-5.7.2_rc1.ebuild) >>> emerge (1 of 2) net-misc/curl-7.26.0 to / === (1 of 2) Cleaning (net-misc/curl-7.26.0::/usr/portage/net-misc/curl/curl-7.26.0.ebuild) >>> emerge (1 of 1) dev-vcs/gitolite-3.04 to / === (1 of 1) Cleaning (dev-vcs/gitolite-3.04::/usr/portage/dev-vcs/gitolite/gitolite-3.04.ebuild) *** Finished. Cleaning up... *** exiting unsuccessfully with status '1'. *** terminating.
I think /etc/ld.so.conf.d/05-gcc-*.conf is generated by gcc-config, so one of the pkg_* phases of the gcc ebuilds would have to call gcc-config in order to update that.
I don't think there's anything portage can do here, other than call ldconfig which it already does.
*** Bug 433724 has been marked as a duplicate of this bug. ***
I'm seeing the same issue on my armv5tel system. Here's my emerge --info (gcc is hosed because of the failure during installation): raven ~ # emerge --info !!! No gcc found. You probably need to 'source /etc/profile' !!! to update the environment of this terminal and possibly !!! other terminals also. Portage 2.1.11.9 (default/linux/arm/10.0/armv5te/server, [unavailable], glibc-2.14.1-r3, 3.4.10 armv5tel) ================================================================= System uname: Linux-3.4.10-armv5tel-Feroceon_88FR131_rev_1_-v5l-with-gentoo-2.1 Timestamp of tree: Mon, 03 Sep 2012 21:45:01 +0000 app-shells/bash: 4.2_p20 dev-lang/python: 2.7.3-r2, 3.2.3 dev-util/cmake: 2.8.7-r5 dev-util/pkgconfig: 0.27 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.9.8.4 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.68 sys-devel/automake: 1.11.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.5.4 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 3.4-r2 (virtual/os-headers) sys-libs/glibc: 2.14.1-r3 Repositories: gentoo mythtv x-portage-overlay ACCEPT_KEYWORDS="arm" ACCEPT_LICENSE="* -@EULA" CBUILD="armv5tel-softfloat-linux-gnueabi" CFLAGS="-O2 -pipe -march=armv5te" CHOST="armv5tel-softfloat-linux-gnueabi" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -pipe -march=armv5te" DISTDIR="/usr/portage/distfiles" FCFLAGS="-Os -march=armv5te -fomit-frame-pointer" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles news parallel-fetch parse-eapi-ebuild-head protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-Os -march=armv5te -fomit-frame-pointer" GENTOO_MIRRORS="http://distfiles.gentoo.org" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en en_US" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/mnt/auto/portage" PORTDIR_OVERLAY="/usr/local/mythtv_portage/Gentoo /usr/local/portage-overlay" SYNC="rsync://jove.eng.yale.edu/gentoo-portage" USE="arm berkdb bzip2 cli cracklib crypt cxx fortran gdbm gpm iconv ipv6 lzma memlimit modules mudflap ncurses nls nptl offensive openmp pam pcre pppd readline session ssl tcpd truetype unicode xml zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en en_US" PHP_TARGETS="php5-3" PYTHON_TARGETS="python2_7" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="dummy" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON raven ~ #
*** Bug 435902 has been marked as a duplicate of this bug. ***
*** Bug 436806 has been marked as a duplicate of this bug. ***
*** Bug 437050 has been marked as a duplicate of this bug. ***
*** Bug 437100 has been marked as a duplicate of this bug. ***
I'm unsure about the order of postinst and postrm of the two involved packages (it happened to me while upgrading gcc 4.7.1 to 4.7.2 on armv5), but I would suggest the following: After the new version got installed (merged) and _before_ the old version got removed, update /etc/env.d/gcc* and rebuild the stuff in /etc/ld.so.conf.d. Currently this only seems to happen after the old version got removed, which is to late. In my case everything failed starting with postrm of 4.7.1 and the stuff in /etc/env.d couldn't get updated.
Created attachment 327182 [details, diff] Patch for toolchain.eclass I've attached a fix for the toolchain.eclass. This will make sure that the dynamic linker will always find a version of the gcc libraries. One problem remains, this patch will not help if e.g. gcc 4.7.1 is already installed and you want to upgrade to 4.7.2. The problem with that is that the new pkg_prerm in the toolchain.eclass will not be called for already installed packages. Those are using the stuff in /var/db/pkg/sys-devel/gcc-x.y/environment.bz2 which contains the old toolchain.eclass. But it is possible to circumvent that problem too using a horrible but working workaround. I will just describe the (temporary) workaround and will maybe offer a patch for that later: In pkg_preinst, copy the new libgcc_s.so to the final destination and run ldconfig afterwards. The real install will then just overwrite it, maybe with it warning, but at least it will be found after the old libgcc_s.so is deleted and before gcc-config was run. Another fix would be to update the environment for already installed versions of gcc. I don't know if there is already some mechanism to do such.
Regardless if and which workaround will be used (later on), the faster toolchain.eclass will be updated, the less people will be affected because newly installed gcc's will have the pkg_prerm (and pkg_preinst, but the latter isn't important for already installed gcc's).
Because I think an explanation might be usefull about what happens, here is the sequence, stuff marked with NEW is new with my patch. (1) NEW preinst new_gcc, creates a temporary file in ld.so.conf.d (2) new_gcc and his libs will be installed (3) NEW prerm old_gcc, calls ldconfig (new libs and temp file will be recorded) (4) old_gcc will be removed (old libgcc_s.so disappears) (5) postrm old_gcc (6) postinst new_gcc, calls gcc-config Without the (new) steps (1) and (3) the runtime linker will not find the new libgcc_s.so after step (4), therefor gcc-config doesn't work.
One last note: The problem only arises when updating gcc in the same slot while no other version of gcc (in another slot) is installed.
Instead if a workaround (in addition to the attached patch), people could be advised to first recompile/reinstall their old gcc (so that the pre_rm in the new toolchain.class becomes effective) before upgrading to a new version of gcc with the same slot.
Alexander, thanks for your work on this. Just to verify, in order to safely update my gcc, I need to: 1) patch toolchain.eclass with your patch 2) re-emerge the same version of gcc as I already have installed 3) emerge -u world as normal Is that correct? Is there a reason to worry if the toolchain.eclass patch is reverted the next time I emerge --sync?
Exactly. Just don't forget to patch toolchain.eclass again after every sync, or at least before you install or upgrade (sometime in the future) gcc (again).
Just got hit by this bug, and it is very annoying. I suspect it hasn't shown up much, because there wasn't a stable gcc update in the same slot for a long time in gentoo. I had this error first after migrating from a split-/usr to nonsplit, where 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. After that I hit this bug after a gcc slot update (other older versions where still installed). See http://forums.gentoo.org/viewtopic-p-7053126.html for other cases.
I think I now know the reason why that problem hits mostly users on ARM. On x86 many software doesn't have need to link against libgcc_s.so, so it isn't very likely that something fails in the short time while that library isn't accessible. On arm it is different. There, even many coreutils need that library. Therefor it is extremly likely that somethings fails if that library isn't available. See e.g. bug #454030 which made aware of that fact.
*** Bug 471862 has been marked as a duplicate of this bug. ***
*** Bug 472272 has been marked as a duplicate of this bug. ***
*** Bug 476262 has been marked as a duplicate of this bug. ***
*** Bug 491240 has been marked as a duplicate of this bug. ***
We really need to fix this. It's breaking systems on every version bump, and not just on arm. I don't think the posted patch is the right approach, but I'm not sure what is.
(In reply to Alexander Holler from comment #13) > One last note: The problem only arises when updating gcc in the same slot > while no other version of gcc (in another slot) is installed. That's not true. This bug hits me every time I upgrade gcc-4.8, which isn't my system gcc (4.7.3 is) and hasn't even been used to compile any package on my system. (In reply to Alexander Holler from comment #18) > I think I now know the reason why that problem hits mostly users on ARM. > > On x86 many software doesn't have need to link against libgcc_s.so, so it > isn't very likely that something fails in the short time while that library > isn't accessible. I'm on amd64 and pretty much nothing except busybox (which is statically linked) works anymore when this bug appears. Not sure why it's different for others.
It just broke my system (amd64). I did not recognized it and restarted my box. It did not boot :-(. Luckily I've second system where I prepared boot usb. Then just made a symlink to allow boot broken system again. Ugly bug.
(In reply to haarp from comment #24) > (In reply to Alexander Holler from comment #13) > > One last note: The problem only arises when updating gcc in the same slot > > while no other version of gcc (in another slot) is installed. > That's not true. This bug hits me every time I upgrade gcc-4.8, which isn't > my system gcc (4.7.3 is) and hasn't even been used to compile any package on > my system. > I have the same setup. System is gcc-4.7.3 and latest gcc-4.8 (not used) > (In reply to Alexander Holler from comment #18) > > I think I now know the reason why that problem hits mostly users on ARM. > > > > On x86 many software doesn't have need to link against libgcc_s.so, so it > > isn't very likely that something fails in the short time while that library > > isn't accessible. > I'm on amd64 and pretty much nothing except busybox (which is statically > linked) works anymore when this bug appears. Not sure why it's different for > others. I don't remember exactly, but system was not able to mount /run file system, so no service started. Login prompt was shown, but I was not able to login.
Just got hit again when unmerging gcc-4.8.2 (which is not my system gcc). All that needs to be done during unmerge: - adjust /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf - run ldconfig BEFORE acctually removing any files. That should solve the problem...
Created attachment 377272 [details] gentoo-gcc-bug-433161 Because the old patch didn't apply cleanly anymore, I've attached a handy patch-script to put into /etc/portage/postsync.d (I've used the descriptive name gentoo-gcc-bug-433161, but that's up to you, don't forget chmod +x). After doing so, you have to recompile your installed gcc version(s) *once* after you have synced or executed this script (to update the stuff in /var/db/pkg, reason explained above) and afterwards you can forget this bug as long as the patch applies. Alexander Holler
Just in case the toolchain.eclass will be updated, you should add -N to the options for patch in the script.
You can reproduce this bug on any system (for example amd64): 1. Use gcc-4.8.3 as system compiler 2. Emerge gcc-4.9.1 3. Delete gcc-4.9.1 4. libgcc_s.so.1 is not found (In reply to Zac Medico from comment #2) > I don't think there's anything portage can do here, other than call ldconfig > which it already does. No, it doesn't, because portage has failed before "ldconfig" call. Portage has failed even before "gcc-config" call and user can't use it too. I had to do: 1. sudo cp /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1 /lib64 2. sudo -i 3. export LD_LIBRARY_PATH="/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/" 4. rm /lib64/libgcc_s.so.1 5. gcc-config 1 6. ldconfig 7. exit This is definitely critical bug. I can offer some solution - you can use LD_LIBRARY_PATH to store current gcc libpath, than update compiler, than unset LD_LIBRARY_PATH.
The attachment gentoo-gcc-bug-433161 should help there too. Just follow comments #28 and #29. The patch still apllies (but -N is now really needed).
I have been hitting this issue on my multilib amd64 desktop for about 2 years now, most recently a few days ago going from gcc 4.8.3 to 4.8.4. I do not seem to have the issue on my laptop, which is 64-bit only. emerge --info: Portage 2.2.15 (python 2.7.9-final-0, default/linux/amd64/13.0, gcc-4.8.4, glibc-2.20-r1, 3.16.3-gentoo x86_64) ================================================================= System uname: Linux-3.16.3-gentoo-x86_64-AMD_Phenom-tm-_II_X6_1055T_Processor-with-gentoo-2.2 KiB Mem: 16409708 total, 7283268 free KiB Swap: 0 total, 0 free Timestamp of tree: Tue, 27 Jan 2015 18:45:01 +0000 sh bash 4.3_p33-r1 ld GNU ld (Gentoo 2.24 p1.4) 2.24 ccache version 3.2.1 [disabled] app-shells/bash: 4.3_p33-r1 dev-java/java-config: 2.2.0 dev-lang/perl: 5.20.1-r4 dev-lang/python: 2.7.9-r1, 3.2.5-r6, 3.3.5-r1, 3.4.2 dev-util/ccache: 3.2.1-r1 dev-util/cmake: 3.1.0 dev-util/pkgconfig: 0.28-r2 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.13.8 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.14.1, 1.15 sys-devel/binutils: 2.24-r3 sys-devel/gcc: 4.6.4, 4.8.4 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.5 sys-devel/make: 4.1-r1 sys-kernel/linux-headers: 3.18 (virtual/os-headers) sys-libs/glibc: 2.20-r1 Repositories: gentoo gentoo-haskell wine-d3dstream glc anders-larsson ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O3 -pipe -fomit-frame-pointer -flto=7 -fuse-linker-plugin" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/lang uage.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=native -O3 -pipe -fomit-frame-pointer -flto=7 -fuse-linker-plugin" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS=" --jobs --load-average=5.75" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-lo gs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://128.61.111.9/pub/gentoo rsync://mirrors.rit.edu/gentoo/ http://gentoo.mirrors.pair.com/ rsync://gentoo.mirrors.tds.net/gentoo" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -march=native -O3 -pipe -fomit-frame-pointer -flto=7 -fuse-linker-plugin" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclud e=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/haskell /var/lib/layman/wine-d3dstream /var/lib/layman/glc /var/lib/layman/anders-larsson" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac aacplus aalib acpi aio alsa amd64 amr ao apng audiofile autotrace bash-completion berkdb bs2b bzip2 cairo clang cli color colordiff colors corefonts cracklib crypt cscope curl cvs cx x darcs dbus dirac dri dri3 drm emacs equalizer ffmpeg fftw flac fontconfig fortran fpx ftgl g3dvl gbm gdbm gif git glut gmp gnutls gold gpm graphite graphviz gsm gtk gtk3 gtkstyle gzip harfbuzz helpers iconv icu infinality inotify ithreads jpeg jpeg2k keymap lame latex libcaca libffi libnotify libsamplerate llvm lpsol lto lzma lzo mad matroska mercurial mesa mmap mmx mmxext modules mp3 mp4 mpd mpg123 mplayer multilib nc urses nptl nsplugin ntpl ogg openal opengl openmp openssl osmesa pam pango pcf pch pcre pdf perl png pulseaudio python python3 qt4 readline realtime rtmp schroedinger sdl session sharedmem slang smp sndfile speex spell sqlite sqlite3 sse sse2 sse3 sse4a ssl subversion svg swig theora threads tiff tk truetype twolame udev unicode vdpau vorbis vpx webgl webkit webm webp winbind x264 xattr xcb xft xinerama xv xvfb xvid zlib " ABI_X86="32 64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymf pci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner au thz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif s peling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdt ool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timin g tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="pc" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="p resenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" QEMU_SOFTMMU_TARGETS="x86_64" QEMU_USER_TARGETS ="x86_64" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" USE_PYTHON="2.7 3.3" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, MAKEOPTS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Actually, at the time I had MAKEOPTS set as well. MAKEOPTS="-j -l 6"
If you run into this situation (like I did - again!), where cp, ln, cat, bash, python are broken, lib # cp gcc/armv6j-hardfloat-linux-gnueabi/4.7.4/libgcc_s.so.1 . cp: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory one can get saved by perl: perl -e 'link "/usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/4.7.4/libgcc_s.so.1", "/usr/lib/libgcc_s.so.1";'
Using a statically linked shell like busybox sh or ash to copy the lib to /lib or to create a symlink helps too.
Is there a comprehensive fix for this yet? I've tried a few of the 'fixes' in comments but each one appears to either fail, or be missing some instructions. I hit this after depcleaning the old version of gcc away, believing everything was fine and then it all broke. Fortunately I have binpkg's of the old version and have had to manually unpack it. However from this point I don't know how to continue as I'm on arm, and so don't have /lib64.
There seems to be another related bug with gcc-config failing if 3 versions of gcc are installed. It seems that then ld.so.conf might be wrong and if gcc-config doesn't work correctly, the fixes here can't too.
Hit a strange variant of this bug today on an ARM musl stage-building session with catalyst, whereby stage1 completes correctly, but then stage2 fails because it cannot find 'libgcc_s.so.1' and throws a wobbly attempting to run 'sandbox' emerging packages. This occurred after an upgrade from gcc-7.3.0-r2[?] to gcc-7.3.0-r3 (ie. within the 7.3.0 slot) Chrooting into the offending stage, and running 'env-update' seems to cure it. Other attempts to 'gcc config' does not, and 'ldconfig -p' isn't implemented on musl, so these were the only apparent options. /etc/ld.so.conf contents, as well as /etc/env.d/00musl & 04gcc<etc> all checked out OK. Discussion on IRC with slyfox suggested most likely a similar situation to #c30 whereby libgcc_s.so.1 'disappears' before ldconfig/etc is run. Posting here to record incident, and in case anyone else discovers, and to follow up if the problem persists.
How gcc should work (in my understanding): 1. gcc ebuild installs (or removes) /etc/env.d/gcc/${CHOST}-${PV} 2. gcc ebuild regenerates /etc/ld.so.conf.d/05gcc-${CHOST}.conf (runs gcc-config in toolchain_pkg_post* phases) 3. portage runs ldconfig (via env-update). Happens after every package install/uninstall. Current code lives around 'do_gcc_config()' in: https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/toolchain.eclass But something goes wrong here. We need to find out what precisely. Some guesses: a) [2.] does not always happen. Should fixed by tweaking 'do_gcc_config()' b) [2.] and [3.] go in incorrect order. That might be more nuanced. c) Something else.
(In reply to Sergei Trofimovich from comment #39) > How gcc should work (in my understanding): > > 1. gcc ebuild installs (or removes) /etc/env.d/gcc/${CHOST}-${PV} > 2. gcc ebuild regenerates /etc/ld.so.conf.d/05gcc-${CHOST}.conf (runs > gcc-config in toolchain_pkg_post* phases) > 3. portage runs ldconfig (via env-update). Happens after every package > install/uninstall. > > Current code lives around 'do_gcc_config()' in: > https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/toolchain.eclass > > But something goes wrong here. We need to find out what precisely. > > Some guesses: > a) [2.] does not always happen. Should fixed by tweaking 'do_gcc_config()' > b) [2.] and [3.] go in incorrect order. That might be more nuanced. > c) Something else. Another point: gcc-config also has explicit code to copy libgcc_s.so to /lib*: https://gitweb.gentoo.org/proj/gcc-config.git/tree/gcc-config#n317 I wonder why that code does not work.
I do wonder why version 7.3.1 is reported at various tinderox imaegs nowadays: run/17.0-no-multilib_20181006-211348 [1] x86_64-pc-linux-gnu-7.3.1 [2] x86_64-pc-linux-gnu-8.2.0 * whilst v8 was emerged and selected, 7.3.0-r3 was unmerged before
(In reply to Toralf Förster from comment #41) > I do wonder why version 7.3.1 is reported at various tinderox imaegs > nowadays: > > run/17.0-no-multilib_20181006-211348 > [1] x86_64-pc-linux-gnu-7.3.1 > [2] x86_64-pc-linux-gnu-8.2.0 * > > whilst v8 was emerged and selected, 7.3.0-r3 was unmerged before 7.3.1 comes from ada ebuild, not gcc ebuild: $ dev-lang/gnat-gpl: /usr/x86_64-pc-linux-gnu/gcc-bin/7.3.1/x86_64-pc-linux-gnu-gcc
I think we have fixed (or worked it around) by more aggressive gcc-config calls on most of gcc changes instead of clever heuristics: https://bugs.gentoo.org/680360 Please reopen (or file a new bug) if it still happens to you.
