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)
I agree that this is necessary.
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 :)
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
Forgot to add myself.
Created attachment 201971 [details] libstdc++.txt This list of packages has been updated to depend on ~virtual/libstdc++-3.3.
halcy0n: so all the deps are fixed up now, what's next? Probably adding the new slot I think?
Created attachment 205958 [details] need testing. This ebuild pass compile.
Created attachment 207467 [details] New ebuild with GCC 4.4.2 and moved to slot 6
Created attachment 207469 [details, diff] Don't build crt*.o and libgcc with SSP
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.
i think this is largely not necessary
