On Sunday, November 2, 2008 03:26:14 Ciaran McCreesh wrote: > 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...
Yes it builds in parallel. By compiling it in parallel. I don't know why and don't care to investigate for you. It's not my package, I'm not QA and my team is short staffed enough as it is. We have to take care of our own backyard. Maybe you could investigate the answers to your own questions? How about you at least feign attempt at answering my questions for a change? > > > 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? I agree with the first sentence, never said otherwise. Who says I am not considering them? In fact, I have stated that I am. They are just more hackish than adding the ability to RESTRICT distcc, hence my reason for soliciting such a feature. I'm surprised that you'd suggest this after debasing a RESTRICT option on the same grounds. > > > 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. You can cry "abuse" all you want. You FAIL to offer any alternatives or solutions. I'll ask again, how do you detect that you are compiling code destined to be run in-kernel from within gcc without checking for the __KERNEL__ macro? I think we both know the answer. We can't just hack the eclass to pass -fno-PIE because a particular package might build more than just the kernel module itself. Patching kbuild in our sources doesn't address any modules that don't use in-tree kbuild and is stupid in so many ways anyway. That leaves patching every out-of-tree module in portage manually and maintain those patches forward which would be very time/effort intensive on an ongoing basis. Go ahead and forget about it though. I'm done with this discussion. Because we rely on the __KERNEL__ macro to determine which flags to apply, it only makes sense to patch in-portage distcc in the case of hardened to pass it. And that's exactly what I'll be doing. Problem solved and I like that option better anyway. Sorry to everyone who e-mailed me who thought RESTRICT=distcc would be somewhat useful. > > > 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? Why are you assuming this point is *at all* related to my proposal? It's not. It's about Gentoo. But I stand corrected, a bunch of people rushed to tell me you don't actually determine anything. ;) Gordon Malm (gengor) P.S. I've seen enough of these threads from you to know that you can't help but respond with another post that does a lot of objecting but offers no solutions. Go ahead and post again so you can feel like you had the last word, now is your chance, I won't be posting back.
