| 1 |
On Sat, 1 Nov 2008 15:47:09 -0700 |
| 2 |
Gordon Malm <gengor@g.o> wrote: |
| 3 |
> > It looks to me like hardened is doing entirely the wrong thing. |
| 4 |
> > Thus, the proper fix is to make hardened behave itself. |
| 5 |
> |
| 6 |
> It looks to me like you've already made up your mind. How is |
| 7 |
> hardened doing the entirely wrong thing? What do you propose can be |
| 8 |
> done to "fix" the hardened compiler? What about madwifi-ng? You are |
| 9 |
> getting increasingly narrow in your points of objection. |
| 10 |
|
| 11 |
I suggest you get the hardened upstream people to stop abusing the -D |
| 12 |
switch to gcc. The distcc people suggest the same. |
| 13 |
|
| 14 |
> Parallel building problems can often and should be addressed |
| 15 |
> properly. I don't want the answer to every one that comes along to |
| 16 |
> be to add RESTRICT="distcc". This is something to be addressed |
| 17 |
> through developer documentation that using RESTRICT="distcc" should |
| 18 |
> be a last resort. |
| 19 |
|
| 20 |
Uh, RESTRICT=distcc won't even fix parallel make problems. It'll just |
| 21 |
make them harder to reproduce on some systems. |
| 22 |
|
| 23 |
> However, in practice making a package parallel-make safe isn't always |
| 24 |
> trivial. So what happens in these cases is FEATURES=distcc && die |
| 25 |
> check is put in place killing the emerge chain and requiring user |
| 26 |
> intervention. Either that or the bug just lingers and the compile |
| 27 |
> fails somewhere in the middle... |
| 28 |
|
| 29 |
...or you could use -j1, which whilst being horrible will at least work. |
| 30 |
|
| 31 |
> I don't know about palaudis but this is like a one line patch to |
| 32 |
> portage. But silly me, I thought the package manager was there to |
| 33 |
> support the distribution. |
| 34 |
|
| 35 |
You have yet to demonstrate how RESTRICT=distcc will help. In fact, you |
| 36 |
seem to be demonstrating that all it'll do is make a few people apply a |
| 37 |
'fix' that won't reliably fix anything. |
| 38 |
|
| 39 |
*If* there's a legitimate use for RESTRICT=distcc then I am entirely in |
| 40 |
favour of it. But it looks like there isn't, with every issue being |
| 41 |
either a parallelism issue (which RESTRICT=distcc won't fix), a user |
| 42 |
configuration issue (which RESTRICT=distcc won't fix) or a hardened |
| 43 |
toolchain bug (for which RESTRICT=distcc is massive overkill, and thus |
| 44 |
the wrong solution). You've decided upon a solution before you've |
| 45 |
worked out what the problem is. |
| 46 |
|
| 47 |
-- |
| 48 |
Ciaran McCreesh |
Archives