Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Daniel Campbell]

-----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-----