Bug 231870 – new virtual/libstdc++ is necessary

• Product: Gentoo Linux
• Status: RESOLVED WONTFIX

[Description Doug Goldstein (RETIRED) 2008-07-15 15:29:04 UTC]

Since @system is removed from @world and we need to explicitly depend on libstdc++ in packages which link to it. Currently for gcc 3.4.x and higher libstdc++ there is no virtual to describe that depend. We'd want a virtual because in the future if gcc changes their C++ ABI we'll need to build the old versions.

So basically I propose we add a virtual/libstdc++ with a SLOT="4". In the future we can potentially move virtual/libstdc++v3 over to virtual/libstdc++ with SLOT="3" allowing for EAPI=1 slot based deps to be used. This is however in the future due to the fact that we don't want to bring EAPI=1 into system quiet yet.

This would be used only for packages that expressly link against libstdc++ (i.e. Qt)

[Comment 1 Russell Harmon 2008-09-12 16:36:35 UTC]

I agree that this is necessary.

[Comment 2 Mark Loeser (RETIRED) 2009-05-03 01:02:08 UTC]

Before we can do this, we'll have to fix up some dependencies in the tree.  I'm almost positive not everything in the tree is depending on the exact version they need.

I'll file them as blockers against this bug when I get around to it, unless someone wants to do it before I do :)

[Comment 3 Robin Johnson 2009-08-22 18:31:51 UTC]

As a workaround to avoid EAPI=1 for system at this time, how is this for a plan:

Phase1 (start of migration):
|| ( virtual/libstdc++v3 =virtual/libstdc++-3* )

Phase2 (ready to remove old v3 package):
=virtual/libstdc++-3*

Phase3 (later, when EAPI=1 slot deps enabled):
virtual/libstdc++:3

[Comment 4 Robin Johnson 2009-08-22 18:32:00 UTC]

Forgot to add myself.

[Comment 5 William Hubbs 2009-08-23 02:24:52 UTC]

Created attachment 201971 [details]
libstdc++.txt

This list of packages has been updated to depend on
~virtual/libstdc++-3.3.

[Comment 6 Robin Johnson 2009-08-26 23:31:38 UTC]

halcy0n: so all the deps are fixed up now, what's next?

Probably adding the new slot I think?

[Comment 7 Magnus Granberg 2009-10-03 19:41:39 UTC]

Created attachment 205958 [details]
need testing.

This ebuild pass compile.

[Comment 8 Magnus Granberg 2009-10-18 12:18:22 UTC]

Created attachment 207467 [details]
New ebuild with GCC 4.4.2 and moved to slot 6

[Comment 9 Magnus Granberg 2009-10-18 12:19:33 UTC]

Created attachment 207469 [details, diff]
Don't build crt*.o and libgcc with SSP

[Comment 10 Anthony Basile 2009-10-20 13:00:52 UTC]

I've tested the resulting libraries from the ebuilds in the previous three comments against seamonkey-bin, opera, virtualbox-bin and bitdefender-console and found no issues.  I also tested them against my own C++ code and again found no issues whatsoever.

[Comment 11 SpanKY 2014-11-01 03:59:08 UTC]

i think this is largely not necessary