Dnia 2014-12-09, o godz. 14:23:21
Tomas Mozes <tomas.mo...@shmu.sk> 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

Attachment: pgpMeIVgBku8E.pgp
Description: OpenPGP digital signature

Reply via email to