On Sat, 1 Nov 2008 18:29:03 -0700 Gordon Malm <[EMAIL PROTECTED]> wrote: > 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.
Have you conclusively established that they do build fine in parallel? If so, how? And why do they break in parallel only under distcc? Given how distcc works, this strikes me as somewhat implausible... > 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.... RESTRICT=distcc on kernel modules is unnecessary for the large proportion of users who don't use hardened. RESTRICTs can't be set dependent upon whether or not something like hardenened is enabled; other mechanisms are available that can be. So why aren't you considering those other mechanisms? > 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? A macro is just a macro. All it does is affect the preprocessor stage. Hardened is trying to abuse it for something else entirely, which is why you're encountering problems. > What makes it any better than a simple option to RESTRICT distcc? You still appear to be confusing "RESTRICT distcc" and "provide a mechanism for selectively disabling distcc". They are entirely different things. > 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? Uh, that's your answer to technical objections to a proposal? You aren't prepared to defend your proposal on its merits? -- Ciaran McCreesh
signature.asc
Description: PGP signature
