After upgrading my system to baselayout 1.9.4, on rebooting I got a panic due to init being unable to start. Booting with init=/bin/sh revealed the following: ldd /sbin/init linux-gate.so.1 => (0xffffe000) libgcc_s.so.1 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/libgcc_s.so.1 (0x40031000) libc.so.6 => /lib/libc.so.6 (0x4003b000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Temporarily worked around by copying this library into /lib to enable system to boot. This doesn't seem like a good idea, though... Reproducible: Always Steps to Reproduce: 1. Update to baselayout 1.9.4 2. ldd /sbin/init 3. Actual Results: System panic on boot - attempted to kill init. Expected Results: Normal system boot. Portage 2.0.50-r8 (default-x86-1.4, gcc-3.3.3, glibc-2.3.3_pre20040420-r0, 2.6.7) ================================================================= System uname: 2.6.7 i686 AMD Athlon(tm) XP 1800+ Gentoo Base System version 1.4.16 distcc 2.13 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -mcpu=athlon-xp -march=athlon-xp -funroll-loops -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -mcpu=athlon-xp -march=athlon-xp -funroll-loops -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distcc sandbox userpriv usersandbox" GENTOO_MIRRORS="http://proserpine.haus/ http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/ http://gentoo.mirrors.pair.com/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo/" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X aalib acpi alsa apm avi berkdb cdr crypt cups curl dga dvd dvdr encode flac foomaticdb gdbm gif gnome gpm gtk gtk2 imagemagick imlib java jpeg kde libg++ libwww lirc mad matroska mbox mikmod mmx motif mozilla mpeg ncurses nls nptl oggvorbis opengl oss pam pdflib perl png python qt quicktime readline scanner sdl slang spell sse ssl svga tcpd truetype usb x86 xface xml xml2 xmms xv zlib"
emerge -pv baselayout Calculating dependencies ...done! [ebuild R ] sys-apps/baselayout-1.9.4-r2 -bootstrap -build -debug -livecd -selinux -static -uclibc 0 kB solar@simple solar $ ldd `which init` libc.so.6 => /lib/libc.so.6 (0x2dc28000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2dc01000) I'm using.. 3.3.3-r6, binutils-2.15.91.0.1, glibc-2.3.3.20040420 I assume you should not put libgcc_s.so.1 in /lib at all, but if the problem persists for you that you might want to enable static for this package. It was noted that integer multiplication or division may every well be the cause of how libgcc could get linked in. A shot in the dark here.. But maybe compiled with -fstack-protector way back in the day and it's pulling it's __guard symbols from libgcc vs libc. In any direction I'd upgrade to the current stable toolchain.
Updating to a new glibc and gcc fixed things, it seems. Re-emerging baselayout and coreutils cleans those up as well. Thanks. (I wonder if this could possibly be some sort of hangover from the binutils "as-needed" flag problems a while back? The quick fix at the time involved removing the as-needed flag from gcc's specs file and rebuilding things. Could that have caused it to link in libgcc_s unnecessarily?)
Yeah it could have if anything called -shared I'm closing this bug as WORKFORSOME
Reopening bug.. See the blocker..
gcc-config works around this now by copying libgcc_s to /lib/
I just got bitten with this on amd64. Could it be that this is not really solved? After emerging baselayout-1.11.9-r1 it wouldn start anymore. I did run gcc-config (gcc-config-1.3.9), but no libgcc_s.so is in /lib. They are in /usr/lib/gcc-lib/x86_64.../lib64/ After linking libgcc_s to the right places, it boots up again. So running "gcc-config 1" (which is my current gcc-3.4.3.20050110) wouldn't help here.
