I think this deserves even graver severity than major, but you be the judge. gcc 3.1.1 puts the file libgcc_s.so.1 to the directory /usr/lib/gcc-lib/i686-pc-linux-gnu/3.1.1/ This causes major problems during bootup, when my /usr partition hasn't yet been mounted, and prevents my computer from booting. I had to boot with a rescue disk to copy libgcc_s.so.1 to /lib.
Examples maybe ? Was this after an update to 3.1.1, or a new system ?
The exact same thing happened to me and I haven't finished getting my computer back againg because I can't find a rescue. This happened to me on a an already up and going system. I updated gcc, everything looked okay, so I unmerged the old. lib_gcc wasn't put in a very accessible place and nothing would start. I restarted and init fails on /bin/bash being unable to find lib_gcc.
I upgraded from gcc 3.1 to gcc 3.1.1 and pruned the old gcc from my harddisk (emerge prune gcc). After this libgcc_s.so existed in /usr/lib/gcc-lib, and could not be accessed before /usr is mounted. I'm not sure what examples Martin requested, but /bin/bash links to libgcc_s, as Andrew mentioned.
I had the same problem, what I did was the following: -emerge -u gcc (had gcc-3.1-r7 before) -emerge clean (gcc-3.1-r7 removed) -tried to compile kde3 cvs, but it complained about missing libgcc_s.so.1 -also found out that emerge was not working, complained about the same file -copied libgcc_s.so.1 to /lib and had a working environment again
Ok. Any chance one of you guys could verify this with a gcc-3.1.1-r1 build from scratch? Would like to know if it is a general issue, or only if upgrading. I havent had any reports from devs who are testing the gcc-3.2_pre build cd, so am thinking it could be an issue when upgrading. Also check that /etc/env.d/05gcc contains the correct directory. Thanks.
LDPATH=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.1.1 is in /etc/env.d/05gcc I don't know if that's the right path or not. Immediately after updating no new programs would run. They all complained about not being able to find libgcc_s.so.1. After running env-update, this problem went away. It wasn't until I restarted that there were any real problems. (thats when I moved the so to /lib and the problem was solved)
I've experienced this problem as well using gcc-3.2. It's only a problem if you have / and /usr on separate partitions as the so can't be found until /usr is mounted. I solved this by cp -r the /usr/lib/gcc-lib directory on to / this works for boot and then /usr is mounted over the top. It would seem that a solution is to copy this lib to /lib when emerging gcc??
Spooky Ghost: New system, or updated a 1.2/1.3 system to gcc-3.2 ?
This is a serious problem, I would consider it critical. Having needed binaries in /bin dynamically linked to libraries in /usr is more than just a major problem. I had the same problem with gcc 3.2 while updating from Gentoo 1.2 to 1.4rc1 bash ended up being linked to libgcc_s in /usr and I had to copy it into /usr to get it to boot. One of the machines in my rack had Gentoo 1.4rc1 installed from scratch (not by me), and bash did not end up linked in this way. I installed Gentoi 1.4 (the hidden one prior to the 1.4rc1 release) on 4 different machines and bash did not end get linked this way. So from my experience, it is only on an upgreade, and not on a clean install. Some posts concerning this can be found at http://forums.gentoo.org/viewtopic.php?t=15590 and http://forums.gentoo.org/viewtopic.php?t=15633
Yep. Question is basically: dont break upgrades, or break gcc multi-version support, with possible complications later on because gcc libs is all over? Fact is (my opinion), gcc is better off the way it is now, than before. If a user have to upgrade, rather reinstall, or if complications, then we should just verify that there is docs with a solution as how to fix. Carpaski: can you mention the 'cp libgcc_s.so /lib' fix in your upgrade docs as a solution for this problem (if the user run into it ... ) ?
see sys-devel/gcc-compat ebuild It wraps all the current gcc-libs into an ebuild and touches them. DRobbins had suggested copying everything, but I made this as it doesn't leave anything unmanaged. Now the issue with the /bin links into /usr... Shouldn't /{s}bin be static...?
assigned
assuming you'll want to resolve this? (reassigning)
Well, 1.4 and gcc-3.2/3.2.1 are proofe that my comments in #10 is valid. The problem was really the same type of issue as a gcc-3.1 to gcc-3.2 upgrade. Anybody still on gcc-3.1.1 should just reinstall using the 1.4 profile. My opinion: 1) Close this as WONTFIX 2) Leave open for people that could still have issues.
closed bugs are searched by default query now
