Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 84961 - gcc forces libstdc++-v3-3.3.4 on me.
Summary: gcc forces libstdc++-v3-3.3.4 on me.
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
: 94760 94786 94870 94963 94966 94971 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-03-12 04:06 UTC by Bjarke Istrup Pedersen (RETIRED)
Modified: 2008-11-05 18:55 UTC (History)
13 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bjarke Istrup Pedersen (RETIRED) gentoo-dev 2005-03-12 04:06:36 UTC
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.
Comment 1 Carsten Lohrke (RETIRED) gentoo-dev 2005-03-12 05:13:53 UTC
`fix_libtool_files.sh` is your friend

*** This bug has been marked as a duplicate of 73435 ***
Comment 2 Bjarke Istrup Pedersen (RETIRED) gentoo-dev 2005-03-12 05:33:42 UTC
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.
Comment 3 Carsten Lohrke (RETIRED) gentoo-dev 2005-03-12 06:33:43 UTC
Ah sorry, pawlow reflex. ;)
Comment 4 Jakub Moc (RETIRED) gentoo-dev 2005-06-02 00:10:04 UTC
Looks like gcc-3.4.4 no longer forces PDEPEND on libstdc++-v3
Comment 5 SpanKY gentoo-dev 2005-06-02 08:54:00 UTC
3.4.4 no longer forces DEPEND
Comment 6 Jakub Moc (RETIRED) gentoo-dev 2005-06-02 15:28:44 UTC
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?
Comment 7 SpanKY gentoo-dev 2005-06-02 16:24:33 UTC
*** Bug 94760 has been marked as a duplicate of this bug. ***
Comment 8 SpanKY gentoo-dev 2005-06-02 16:24:51 UTC
*** Bug 94870 has been marked as a duplicate of this bug. ***
Comment 9 Jakub Moc (RETIRED) gentoo-dev 2005-06-02 16:35:05 UTC
*** Bug 94786 has been marked as a duplicate of this bug. ***
Comment 10 Krzysztof Pawlik (RETIRED) gentoo-dev 2005-06-03 06:40:29 UTC
IMHO: binary only packages should depend on libstdc++-v3 if system has gcc only
>= 3.4.4
Comment 11 Giacomo Perale 2005-06-03 09:49:23 UTC
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?
Comment 12 SpanKY gentoo-dev 2005-06-03 16:46:17 UTC
*** Bug 94959 has been marked as a duplicate of this bug. ***
Comment 13 SpanKY gentoo-dev 2005-06-03 16:46:17 UTC
*** Bug 94963 has been marked as a duplicate of this bug. ***
Comment 14 SpanKY gentoo-dev 2005-06-03 20:40:07 UTC
*** Bug 94971 has been marked as a duplicate of this bug. ***
Comment 15 Bjarke Istrup Pedersen (RETIRED) gentoo-dev 2005-06-03 20:45:34 UTC
#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.
Comment 16 Jakub Moc (RETIRED) gentoo-dev 2005-06-04 00:52:29 UTC
*** Bug 94966 has been marked as a duplicate of this bug. ***
Comment 17 Felix Braun 2005-06-04 07:18:11 UTC
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.
Comment 18 Dan A. Dickey 2005-06-04 07:43:12 UTC
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. 
 
Comment 19 Jakub Moc (RETIRED) gentoo-dev 2005-06-04 07:49:48 UTC
(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.
Comment 20 Giacomo Perale 2005-06-04 07:53:47 UTC
(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 21 alex f 2005-06-05 15:15:48 UTC
Comment #18 helped a lot and fixed it for me.
Comment 22 Daniel Black (RETIRED) gentoo-dev 2005-06-06 00:36:54 UTC
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? 
Comment 23 Jakub Moc (RETIRED) gentoo-dev 2005-06-06 03:05:25 UTC
(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.

Comment 24 SpanKY gentoo-dev 2005-10-31 05:46:08 UTC
*** Bug 108773 has been marked as a duplicate of this bug. ***
Comment 25 Georg Müller 2006-01-24 06:22:47 UTC
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.
Comment 26 ferret 2006-05-12 04:11:33 UTC
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. :)
Comment 27 SpanKY gentoo-dev 2006-09-08 19:47:23 UTC
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
Comment 28 Yannick Koehler 2008-11-05 18:55:46 UTC
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?