Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: Tomas Mozes <tomas.mozes@××××.sk>
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
Date: Tue, 09 Dec 2014 13:53:01
Message-Id: 20141209145234.44701b56@pomiot.lan
In Reply to: Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing by Tomas Mozes
1 Dnia 2014-12-09, o godz. 14:23:21
2 Tomas Mozes <tomas.mozes@××××.sk> napisał(a):
3
4 > On 2014-12-07 11:37, Michał Górny wrote:
5 > > Hello, developers and users.
6 > >
7 > > As some of you know, the toolchain packages in Gentoo suffer from
8 > > lack-of-sanity issues and their maintainers are completely unwilling to
9 > > improve things. I have finally decided to start working on a fork of
10 > > the sys-devel/gcc ebuilds, and I have some bits ready for initial
11 > > testing in 'mgorny' repo, so I would like to know your opinion.
12 > >
13 > >
14 > > Before you start, the shortcomings are:
15 > >
16 > > 1. No cross-compilation support. If the project proves being a success
17 > > it will be readded at some point. However, I will likely fork glibc
18 > > first and work on a sane crossdev alternative.
19 > >
20 > > 2. No gcj support. Since the ebuild has been forked out of
21 > > toolchain.eclass, and the gcj support suffers a lot of issues there, I
22 > > decided there's no point in copying the code. Not sure if anybody
23 > > actually uses it, and if it is actually useful for anything but will
24 > > probably get reintroduced one day [above 'if' applies too].
25 > >
26 > > 3. No bootstrapping, fallbacks and possible some other random feature
27 > > support. The goal was pretty much to get gcc compiling first, and avoid
28 > > awful lot of effort if things prove to have no future.
29 > >
30 > > 4. Hardened is not tested. I think I have copied all the needed code
31 > > and fixed some stuff but I have no clue if it still works ;).
32 > >
33 > >
34 > > Now, the major changes are:
35 > >
36 > > 1. Most of the insanity removed. No more toolchain.eclass. The ebuild
37 > > has just the code for the current gcc version. You can read it and know
38 > > what it does, you don't have to parse a few dozen version conditionals,
39 > > runtime conditionals and random crap code that doesn't do anything in
40 > > some gcc versions. In fact, I think I removed most of the no-op code.
41 > > And now you can actually change something in the ebuild without caring
42 > > for gcc3.4, or without breaking stuff for stable ebuilds.
43 > >
44 > > 2. USE flags are supposed to work. I've replaced the cases when they
45 > > were silently ignored with REQUIRED_USE. I've also removed the silent
46 > > removals when they didn't work -- so if your current toolchain is
47 > > broken, things may actually fail instead of giving your different gcc
48 > > than you wanted. Probably deserves explanatory pkg_pretend() at some
49 > > point, with messages like 'disable USE=-foo because your toolchain is
50 > > broken'.
51 > >
52 > > 3. Things simplified where they could have been simplified. For
53 > > example, I removed the big gcc executable moving function and replaced
54 > > it with --enable-version-specific-runtime-libs. It was enabled in
55 > > toolchain.eclass with a comment 'If we enable it on non-Darwin we screw
56 > > up the behaviour this eclass relies on.' So yep, precious cargo cult --
57 > > why enable something that would require you to remove your useless
58 > > complex function?!
59 > >
60 > > 4. Added gx86-multilib love. Now you have abi_* flags to control
61 > > the compiler runtime. Of course, since gcc is a pile of random modules
62 > > not fit for one another it has different code for different targets. In
63 > > particular, on mips you can't do two ABIs -- either single one
64 > > (non-multilib) or all three of them (--enable-multilib).
65 > >
66 > > 5. Added multilib gcc wrappers. Long story short, multilib gcc now
67 > > shows up in gcc-config alike crossdev -- but unlike i686 crossdev, it
68 > > doesn't screw up your system! Of course, the final implementation may
69 > > differ since it's an early idea but it works. Now distcc happily builds
70 > > stuff for your x86 clients.
71 > >
72 > > 6. Added missing dependencies. Yep, USE flags now, say, pull in doxygen
73 > > rather than silently skipping doc build when it's not installed...
74 > >
75 > > 7. Disabled bootstrap by default (and in fact completely for now). It
76 > > is not *that* useful, and means time savings (and distcc support):
77 > >
78 > > Thu Nov 6 20:39:31 2014 >>> sys-devel/gcc-4.9.2
79 > > merge time: 1 hour, 56 minutes and 43 seconds.
80 > >
81 > > Sun Dec 7 10:46:08 2014 >>> sys-devel/gcc-4.9.2-r100
82 > > merge time: 34 minutes and 55 seconds.
83 > >
84 > >
85 > > If you're interested in testing it, 'layman -a mgorny' and enjoy. I'd
86 > > appreciate any bug reports, except for those covering things i've
87 > > already listed as missing :). Any further comments will be very helpful
88 > > in deciding on the way forward.
89 > >
90 > > If there is a real interest in my fork, I will probably move it to gx86
91 > > as sys-devel/gcc-mgorny. I will also be happy to work on replacing
92 > > the new versions of original sys-devel/gcc completely. With QA process
93 > > against toolchain.eclass if necessary.
94 >
95 > Thanks, I've tried this on ~amd64. It builds in 10 minutes (wow!),
96 > tested to build some core stuff with it:
97 > kernel 3.17, glibc, coreutils, openssl, ssh...
98 >
99 > All seems to work fine. I'll try to recompile the whole machine with it.
100 >
101 > After emerge, there are these notices:
102 > * QA Notice: command not found:
103 > *
104 > * /var/tmp/portage/sys-devel/gcc-4.9.2-r100/temp/environment: line
105 > 3110: pax-mark: command not found
106 > * /var/tmp/portage/sys-devel/gcc-4.9.2-r100/temp/environment: line
107 > 3111: pax-mark: command not found
108
109 Thanks for the report. I've just fixed the missing inherit.
110
111 --
112 Best regards,
113 Michał Górny