Dnia 2014-12-09, o godz. 14:23:21 Tomas Mozes <[email protected]> napisał(a):
> On 2014-12-07 11:37, 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. > > Thanks, I've tried this on ~amd64. It builds in 10 minutes (wow!), > tested to build some core stuff with it: > kernel 3.17, glibc, coreutils, openssl, ssh... > > All seems to work fine. I'll try to recompile the whole machine with it. > > After emerge, there are these notices: > * QA Notice: command not found: > * > * /var/tmp/portage/sys-devel/gcc-4.9.2-r100/temp/environment: line > 3110: pax-mark: command not found > * /var/tmp/portage/sys-devel/gcc-4.9.2-r100/temp/environment: line > 3111: pax-mark: command not found Thanks for the report. I've just fixed the missing inherit. -- Best regards, Michał Górny
pgpMeIVgBku8E.pgp
Description: OpenPGP digital signature
