This is first and most important patch providing native compile for libstdc++-v3-3.3.4 (libstdc++.so.5) in the amd64 2005.0 profile. As always, I have tried not to break other platforms and isolate amd64 && has_multilib_profile profile. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 52521 [details, diff] patch for libstdc++-v3-3.3.4
"The problem is that only libstdc++.so.5 which it provides, doesn't cover all of the contest of emul-linux-x86-compat package." What do you mean exactly ?
Well, this patch provides native build of the libstdc++.so.5 library only, in the emul-linux-x86-compat package are far more compability libraries included (plus some smpeg stuff).
Jack, could you make a fake ebuild for the emul-linux-x86-compat also, so we can solve this one like the alsa one? BTW. This is listing of the emul-linux-x86-compat package for completeness; libc.so.5 libg++.so.2.7.2 libg++.so.2.7.2.8 libgcc_s.so.1 libsmpeg-0.4.so.0 libsmpeg-0.4.so.0.dummy libstdc++-2-libc6.1-1-2.9.0.so libstdc++-3-libc6.2-2-2.10.0.so libstdc++-libc6.1-1.so.2 libstdc++-libc6.2-2.so.3 libstdc++.so.2.7.2 libstdc++.so.2.7.2.8 libstdc++.so.2.8 libstdc++.so.2.8.0 libstdc++.so.2.9 libstdc++.so.2.9.0 libstdc++.so.5 libstdc++.so.5.0.5 libstdc++.so.6 libstdc++.so.6.0.2 My question is, do we *really* need the < 5.0 libstdc++ ? How about libc.so.5 ? What binary packages are actually depending on them anyway (have searched the portage tree, didn't found any, probably some third party installer stuff?) Dario
Created attachment 52917 [details] Fake ebuild for emul-compat dependencies
The fake ebuild is here ;-) For your question about the need for certains libs, I really can't answer you because, as you said, this libstdc++ is needed for binary packages compiled with "old" gcc (prior to 3.4) and I don't have *any* binary package installed on my system...
Created attachment 52919 [details, diff] patch for lib-compat-1.4 I have overlooked this one, and actually this is all we need here :-)
Created attachment 52920 [details] changed einfo description for fake ebuild I have changed description of fake ebuild to reflect both needed packages, please apply. Thanks, Dario
Created attachment 52921 [details, diff] patch for lib-compat-1.4 Sorry, made a typo in logical comparison, this one wouldn't break other archs ;-)
Created attachment 52922 [details, diff] patch for lib-compat-1.4 - forgot the relative path for patch
Yes ! Very good finding ! ;-)
I've updated the emul ebuild to automatically pull down lib-compat, applied your patches, remerged, and everything seems OK. Just a little warning from a 32bit mplayer (from the forums) : "gmplayer32: /usr/lib32/libstdc++-v3/libstdc++.so.5: no version information available (required by gmplayer32)" Don't know what this means... Also, I updated the blocking of emul package, not to block the fake ebuild ;-)
Created attachment 52925 [details, diff] Block old emul-compat package (lib-compat)
Created attachment 52926 [details, diff] Don't block fake ebuild (libstdc++-v3)
Created attachment 52927 [details] Updated fake ebuild to depend on lib-compat
Great ! I've updated my local tree with your changes, works okay. I am having same message printed out, functionality is not affected though. Perhaps someone more expirienced in the toolchain packages care to comment? My guess would be libgcc_s.so because this is only package difference between old contents of emul-linux-x86-compat and this version?
I've created an overlay for this stuff : http://jackmort.free.fr/gentoo-2005.0-amd64/emul-compat-overlay-1.0.tbz2 If someone wants to test, just create an overlay dir, extract this archive, and remerge packages.
wow, really great work you did, Dario. I'm sure we can use this to create the emul-* packages. However, don't expect this to work before 2006.0, since portage isn't fully multilib-capable yet. The final goal is that *every* library in the tree can be built in 32bit and 64bit, and it would be quite messy to patch every single ebuild out there, so the changes will probably be made in portage itself, not the tree.
i'll close it for now as this is a long-term goal and we'll not need it before 2006.0
