When emerging >=gcc-3.4 , it wants to install libstdc++-v3-3.3.4 . Since I have no binary packages or other stuff that depends on this library, I don't want it. So how about removing it as a dependency, and echo it as postinfo for gcc, so people sees it when emerge of gcc is done? Reproducible: Always Steps to Reproduce: 1. emerge >=gcc-3.4 Actual Results: It installs the libstdc++-v3-3.3.4 library, it shouldn't be mandatory Expected Results: It would tell me, that if I wants to use binary packages, I have to install this package.
`fix_libtool_files.sh` is your friend *** This bug has been marked as a duplicate of 73435 ***
No, the problem is not that some of my program break, the problem is that I don't want the libstdc++-v3-3.3.4 package, which I cannot escape unless I do "emerge gcc --nodeps" . So, remove libstdc++-v3 as a dependency from gcc please.
Ah sorry, pawlow reflex. ;)
Looks like gcc-3.4.4 no longer forces PDEPEND on libstdc++-v3
3.4.4 no longer forces DEPEND
Sorry to reopen, but unfortunately this does not seem like the smartest move. It there a way to check whether particular gcc version provides libstdc++.so.5 so that only packages that need it may depend on libstdc++-v3-3.3.4?
*** Bug 94760 has been marked as a duplicate of this bug. ***
*** Bug 94870 has been marked as a duplicate of this bug. ***
*** Bug 94786 has been marked as a duplicate of this bug. ***
IMHO: binary only packages should depend on libstdc++-v3 if system has gcc only >= 3.4.4
also, maybe I am wrong but suppose that: * user A has got a system compiled with gcc-3.3 and python links to libstdc++.so.5 * user A decide to upgrade to gcc 3.4, so he unmasks gcc 3.4 and compiles it * user A remove gcc 3.3 and with it libstdc++.so.5, without recompiling python before results: * python continues to link to libstdc++.so.5, but this file isn't on the system anymore * no more emerge?
*** Bug 94959 has been marked as a duplicate of this bug. ***
*** Bug 94963 has been marked as a duplicate of this bug. ***
*** Bug 94971 has been marked as a duplicate of this bug. ***
#11> Then user A does it the wrong way, since he/she should recompile every package before removing gcc, so it doesn't happend. This is not just gcc, any other package portage (or any other tool) depends on should not be removed until the package have been rebuilt against the new libraries.
*** Bug 94966 has been marked as a duplicate of this bug. ***
The issue here is that binary packages linked against libstdc++.so.5 should depend on a new virtual/libstdc++5 which is provided by both gcc-3.3.x and libstdc++-v3. This way libstdc++-v3 is only pulled in when the user actually has a package on his system that needs the old version of the library.
Regarding comment 11 ... this was my situation this morning. No python, no emerge. I did some searching and found bug 86218. I looked around a bit on my system, and found libstdc++.so.6 in /usr/lib/gcc/i686-pc-linux-gnu/3.4.4. I set LD_LIBRARY_PATH to this location, and then was able to successfully run gcc-config && env-update. After sourcing /etc/profile, I could once again use emerge. That was a nasty little problem.
(In reply to comment #17) > The issue here is that binary packages linked against libstdc++.so.5 should > depend on a new virtual/libstdc++5 which is provided by both gcc-3.3.x and > libstdc++-v3. This way libstdc++-v3 is only pulled in when the user actually has > a package on his system that needs the old version of the library. Well, some BIG FAT WARNING so that users should not unmerge gcc-3.3.x after upgrade to 3.4.x until they have completed 'emerge -e system && emerge -e world' would be really handy in that case.
(In reply to comment #15) > #11> Then user A does it the wrong way, since he/she should recompile every > package before removing gcc, so it doesn't happend. > This is not just gcc, any other package portage (or any other tool) depends on > should not be removed until the package have been rebuilt against the new > libraries. in the best of all possible worlds, maybe. not in real world.
Comment #18 helped a lot and fixed it for me.
Just some excerpts from a i686-pc-linux-gnu-3.4.3-20050110 to i686-pc-linux-gnu-3.4.4 upgrade. started with emerge 3.4.4 with gcc-3.4.3.20050110-r2 >>> Regenerating /etc/ld.so.cache... * Caching service dependencies... >>> sys-devel/gcc-3.4.4 merged. sys-devel/gcc selected: 3.4.3.20050110-r2 protected: 3.4.4 3.3.5.20050130-r1 omitted: none .... .... cleaning... .... * Scanning libtool files for hardcoded gcc library paths... /usr/bin/python: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory :0: assertion failed: (/usr/bin/portageq envvar 'CHOST') | getline CHOST * Scanning libtool files for hardcoded gcc library paths... /usr/bin/python: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory :0: assertion failed: (/usr/bin/portageq envvar 'CHOST') | getline CHOST >>> Regenerating /etc/ld.so.cache... * Caching service dependencies... >>> Regenerating /etc/ld.so.cache... * Caching service dependencies... >>> Auto-cleaning packages ... This left me with a broken python. Should the LD_LIBRARY_PATH be set for the last bits of the emerge?
(In reply to comment #22) > This left me with a broken python. > Should the LD_LIBRARY_PATH be set for the last bits of the emerge? Wrong bug. ;-) This is Bug 94959 - hopefully fixed now.
*** Bug 108773 has been marked as a duplicate of this bug. ***
I had the problem, that, from a former version(?), the libstdc++.so.6 stuff was in /usr/lib/gcc-lib/... and not in /usr/lib/gcc as stated in /etc/env.d/gcc/... I moved gcc-lib to gcc and my libstdc++.so.6 was found again.
With the new virtual/libstdc++ I notice that it's a PDEPEND in the gcc ebuilds for x86 guys. It seems odd that this virtual was created and then not used specifically for binary packages. On my system at least, I can safely remove this package (having checked with revdep-rebuild and a modified paranoid version of revdep-rebuild which takes five times as long but doesn't use a silly LD_LIBRARY_PATH). Of course, after removing it it wants o come back. :)
gcc no longer forces libstdc++-v3 at all if packages need a specific ABI version of libstdc++, then it's their problem to RDEPEND on it
Question, what if we have 3rd party apps linked with libstdc++.so.5, is there a way for lib-compat module to support the old library?
