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 |