-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/07/2014 04:37 AM, Michał Górny wrote: > Hello, developers and users. > > As some of you know, the toolchain packages in Gentoo suffer from > lack-of-sanity issues and their maintainers are completely > unwilling to improve things. I have finally decided to start > working on a fork of the sys-devel/gcc ebuilds, and I have some > bits ready for initial testing in 'mgorny' repo, so I would like > to know your opinion. > > > Before you start, the shortcomings are: > > 1. No cross-compilation support. If the project proves being a > success it will be readded at some point. However, I will likely > fork glibc first and work on a sane crossdev alternative. > > 2. No gcj support. Since the ebuild has been forked out of > toolchain.eclass, and the gcj support suffers a lot of issues > there, I decided there's no point in copying the code. Not sure if > anybody actually uses it, and if it is actually useful for > anything but will probably get reintroduced one day [above 'if' > applies too]. > > 3. No bootstrapping, fallbacks and possible some other random > feature support. The goal was pretty much to get gcc compiling > first, and avoid awful lot of effort if things prove to have no > future. > > 4. Hardened is not tested. I think I have copied all the needed > code and fixed some stuff but I have no clue if it still works ;). > > > Now, the major changes are: > > 1. Most of the insanity removed. No more toolchain.eclass. The > ebuild has just the code for the current gcc version. You can read > it and know what it does, you don't have to parse a few dozen > version conditionals, runtime conditionals and random crap code > that doesn't do anything in some gcc versions. In fact, I think I > removed most of the no-op code. And now you can actually change > something in the ebuild without caring for gcc3.4, or without > breaking stuff for stable ebuilds. > > 2. USE flags are supposed to work. I've replaced the cases when > they were silently ignored with REQUIRED_USE. I've also removed > the silent removals when they didn't work -- so if your current > toolchain is broken, things may actually fail instead of giving > your different gcc than you wanted. Probably deserves explanatory > pkg_pretend() at some point, with messages like 'disable USE=-foo > because your toolchain is broken'. > > 3. Things simplified where they could have been simplified. For > example, I removed the big gcc executable moving function and > replaced it with --enable-version-specific-runtime-libs. It was > enabled in toolchain.eclass with a comment 'If we enable it on > non-Darwin we screw up the behaviour this eclass relies on.' So > yep, precious cargo cult -- why enable something that would > require you to remove your useless complex function?! > > 4. Added gx86-multilib love. Now you have abi_* flags to control > the compiler runtime. Of course, since gcc is a pile of random > modules not fit for one another it has different code for > different targets. In particular, on mips you can't do two ABIs -- > either single one (non-multilib) or all three of them > (--enable-multilib). > > 5. Added multilib gcc wrappers. Long story short, multilib gcc now > shows up in gcc-config alike crossdev -- but unlike i686 > crossdev, it doesn't screw up your system! Of course, the final > implementation may differ since it's an early idea but it works. > Now distcc happily builds stuff for your x86 clients. > > 6. Added missing dependencies. Yep, USE flags now, say, pull in > doxygen rather than silently skipping doc build when it's not > installed... > > 7. Disabled bootstrap by default (and in fact completely for now). > It is not *that* useful, and means time savings (and distcc > support): > > Thu Nov 6 20:39:31 2014 >>> sys-devel/gcc-4.9.2 merge time: 1 > hour, 56 minutes and 43 seconds. > > Sun Dec 7 10:46:08 2014 >>> sys-devel/gcc-4.9.2-r100 merge time: > 34 minutes and 55 seconds. > > > If you're interested in testing it, 'layman -a mgorny' and enjoy. > I'd appreciate any bug reports, except for those covering things > i've already listed as missing :). Any further comments will be > very helpful in deciding on the way forward. > > If there is a real interest in my fork, I will probably move it to > gx86 as sys-devel/gcc-mgorny. I will also be happy to work on > replacing the new versions of original sys-devel/gcc completely. > With QA process against toolchain.eclass if necessary. >
As a user, what would adopting this do? For instance I run ~amd64 multilib and have had quite a time dealing with the recent multilib changes (specifically with Humble Bundle games). Would you recommend helping you test this simplified and/or cleaned up toolchain on one's primary system, or is it better off for more specific systems that don't need to be as versatile as a multi-purpose desktop machine? Regardless, it seems really ambitious and I hope positive change comes about for the toolchain. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUhC80AAoJEJUrb08JgYgHowwH/A7s/IBm6wbQL2HafNuYCN9f I9MQlHeS7pBaf29u18nDPInFuViGgOfUjQBazhZ9TDdNFxG/EhmNhMfXRC0iIlPs HV9MmPWOgRQCo6E0DtTw81+E2aEPiCurqpKpTtChFZlYgN31z3sx9prevwtH1vyT ikHounODw4ml5aRCfQAm40Hgt+UJ5tre6mS9/3c/smmMSTO1/mxzxhMedHHs5Yol sgghqbzce5TO/LWKFpR1Jti7qF967Y9UVvQUHa/qX+jFDMN2CgIVPWI2I2s9LeW5 rR/xe94lcgJDDhTxeBG5ep0o5JXhAjNeoCq/qgcbhGM1OTzBOI/aOGjYgYa8tfA= =rsQ8 -----END PGP SIGNATURE-----
