Summary: | fix building of sys-devel/gcc-3.3.6 on recent systems | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Carlo Marcelo Arenas Belon <carenas> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | bdouglashilton, bobber205, buro, c.hanauer, clemente.aguiar, ElemonGW, fturtle, jieryn, karl, mmokrejs |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
ebuild for gcc-3.3.6-r3
The makelang patch; needed for installing the ebuild Another necessary patch |
Description
Carlo Marcelo Arenas Belon
2007-12-02 23:28:31 UTC
case 1 was fixed in the last version of gcc-3.3.6-r1.ebuild (version 1.8) which was most likely pushed as part of a fix for bug 159459 but there is no mention to it in the ChangeLog for case 3 architectures that will need to be filtered as reported in the bugs are : athlon64, k8 and pentium-m but there might be others. Created attachment 137589 [details] ebuild for gcc-3.3.6-r3 Adds replace-cpu-flags rules for x86 to alias all newer than 3.3.6 CPU-TYPEs and which should fix the last remaining case open. keyworded ~x86 for stabilization request (needed most likely only for x86) for a full list of changes, see the ChangeLog in the overlay. all required patches uploaded as part of bug 183766 but available from the overlay as well to simplify testing. *** Bug 201386 has been marked as a duplicate of this bug. *** *** Bug 201713 has been marked as a duplicate of this bug. *** I pulled from http://tapir.sajinet.com.pe/gentoo/layman.xml and with one small update [1], I was able to compile and install gcc-3.3.6. I am building qemu right now. Thanks Carlo!! [1] Please update replace-cpu-flags for amd64/x86 nocona and native which point to i686. I emerged with gcc-4.2.2 on core 2 duo, 64-bit. *** Bug 201732 has been marked as a duplicate of this bug. *** And this bug turns into yet another dumpspace for ignored borkage, exactly like Bug 183766. toolchain - kindly drop the keywords from gcc-3.3* so that it stops getting pulled by the darned virtual/libstdc++ until it actually compiles. again, go away. gcc-3.3.6 is being worked on. (In reply to comment #8) > again, go away. gcc-3.3.6 is being worked on. Sigh, nice attitude dude... Why don't you drop the keywords from useless broken ebuilds? You like us getted flooded by these tons of duplicates, like pissed off users, or what exactly is the purpose of this? Why are you wasting other people's time w/ known-to-be-broken stuff? please use this pseudo script for anything further: if (username == jakub && asssigne == toolchain) ; else post comment; i'll use something similar on my side. thanks! What I don't understand is why in hell we're still pulling it in on x86 arch? Didn't 3.4 change the API/ABI significantly towards what gcc4 is now using? If so, why don't we start stripping an obsolete flag from x86 arch and hard masking packages that depend on it? Seems to be the most sensible way to solve the problem as it indicates either the upstream dev aren't interested in fixing the issue (might require major rewrite) or we start dropping them as no longer supported. In the case of Real Player, we need to either get on their ass about still needing the 3.3 toolchain when the 3.4 toolchain would at least have the same ABI on x86 or switch to the community helix player where we have the option to fix the problems as they come up. Personally, I'd rather we make the switch to the helix player in order to get the codec for mplayer, which I assume most of us use in prefernce to realplayer. (In reply to comment #11) > What I don't understand is why in hell we're still pulling it in on x86 arch? Because libstdc++.so.5 is required by some binary cruft, and because with virtual/libstdc++ that's how portage behaves, see Bug 161953. Nothing like this would happen if gcc-3.3 ebuilds were masked pending a fix, or if the keywords were dropped from them at least. Both was refused by the maintainer so users must mask =sys-devel/gcc-3.3* themselves after having wasted their time on compiling something that's bound to fail. Enjoy. *** Bug 201802 has been marked as a duplicate of this bug. *** The attached ebuild doesn't work. * Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: * * /usr/local/portage/sys-devel/gcc/files/gcc-3.3-makelang.patch * ( gcc-3.3-makelang.patch ) There is no gcc-3.3-makelang.patch file in the FILESDIR in the portage tree. Created attachment 138321 [details] The makelang patch; needed for installing the ebuild Downloaded from http://tapir.sajinet.com.pe/gentoo/portage/sys-devel/gcc/files/ Created attachment 138322 [details] Another necessary patch Taken from http://tapir.sajinet.com.pe/gentoo/portage/sys-devel/gcc/files/ Bug 201732 RealPlayer 10 now has a solution: Hard masked gcc-3.3.6 in /portage/profiles/package.mask Real Player 10 forced libstdc++3.3.6 (compatibility lib) usage Real Player 10 now fully functional due to compatibility library usage. Change Real Player Ebuild dependency to libstdc++3.3.6 instead of gcc-3.3.6 *** Bug 202216 has been marked as a duplicate of this bug. *** *** Bug 202938 has been marked as a duplicate of this bug. *** thanks, both patches now in 3.3.6-r1 |