On Saturday, November 1, 2008 15:57:52 Ciaran McCreesh wrote: > > Parallel building problems can often and should be addressed > > properly. I don't want the answer to every one that comes along to > > be to add RESTRICT="distcc". This is something to be addressed > > through developer documentation that using RESTRICT="distcc" should > > be a last resort. > > Uh, RESTRICT=distcc won't even fix parallel make problems. It'll just > make them harder to reproduce on some systems.
Why don't you post the whole context? Here, I'll do it for you: On Saturday, November 1, 2008 15:11:16 Ciaran McCreesh wrote: > > It looks a lot like people are blaming distcc for parallelisation bugs > > that aren't distcc related but that happen to be easier to reproduce > > when distcc is enabled. Do you have any examples of problems that are > > definitely caused by distcc, rather than general parallelisation bugs > > or user misconfigurations? RESTRICTing distcc doesn't seem to be an > > actual fix for anything... > And my full response... > As I said in my first post: > > 'It is true that RESTRICT="distcc" is usually not the proper solution to > problems.' > > Parallel building problems can often and should be addressed properly. I > don't want the answer to every one that comes along to be to add > RESTRICT="distcc". This is something to be addressed through developer > documentation that using RESTRICT="distcc" should be a last resort. You're the one assuming the only purpose would be to mask parallel make problems. Apparently it does have a purpose though since avidemux builds fine in parallel but NOT via distcc. Back to your most recent post > *If* there's a legitimate use for RESTRICT=distcc then I am entirely in > favour of it. But it looks like there isn't, with every issue being > either a parallelism issue (which RESTRICT=distcc won't fix), a user > configuration issue (which RESTRICT=distcc won't fix) or a hardened > toolchain bug (for which RESTRICT=distcc is massive overkill, and thus > the wrong solution). You've decided upon a solution before you've > worked out what the problem is. You assumed it is a parallelism issue that people are trying to solve. I haven't pointed to any user configuration issues. Using RESTRICT=distcc on kernel modules is hardly overkill. This isn't openoffice. I know exactly what the problem is, but since you have such a better grasp on it.... On Saturday, November 1, 2008 15:57:52 Ciaran McCreesh wrote: > On Sat, 1 Nov 2008 15:47:09 -0700 > > Gordon Malm <[EMAIL PROTECTED]> wrote: > > > It looks to me like hardened is doing entirely the wrong thing. > > > Thus, the proper fix is to make hardened behave itself. > > > > It looks to me like you've already made up your mind. How is > > hardened doing the entirely wrong thing? What do you propose can be > > done to "fix" the hardened compiler? What about madwifi-ng? You are > > getting increasingly narrow in your points of objection. > > I suggest you get the hardened upstream people to stop abusing the -D > switch to gcc. The distcc people suggest the same. On Saturday, November 1, 2008 16:28:17 Jan Kundrát wrote: > Gordon Malm wrote: > > It looks to me like you've already made up your mind. How is hardened > > doing the entirely wrong thing? > > From the page [1] you mentioned: > > "If so, that seems to me like an abuse of the -D option." > > The abuse is in changing the compiler behavior based on -D options. > > > What do you propose can be done to "fix" the > > hardened compiler? > > From the same page: > > "It would be better for you to remove the patch from gcc where it makes > -D__KERNEL__ imply -nossp -nopie, and to instead patch the Linux kernel > build system (Makefiles, etc.) so that it passes "-D__KERNEL__ -nossp > -nopie" rather than "-D__KERNEL__"." > We have to build using different specs sets for kernel code than userland. If we can't depend on the __KERNEL__ macro for detection, how else do you propose one detect if gcc is building kernel code or not? Patching an out-of-tree module's build system to pass -fno-PIE works on x86, I don't know how this will affect other ARCHes, do either of you? This could potentially get really tricky. If it can't be done nicely in the eclass for every possible kernel release and out-of-tree module, then we get into patching *everything* and having to maintain it forward. So this is just a different workaround, a rather heavy-handed and high-maintenance one at that. What makes it any better than a simple option to RESTRICT distcc? I guess the larger question in all this is why does a third party who has demonstrated his anti-Hardened (and anti-Gentoo) slant on multiple occasions define what goes in our PMS? Gordon Malm (gengor)
