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

Attachment: signature.asc
Description: PGP signature

Reply via email to