From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1KwRm7-0002GQ-19 for garchives@archives.gentoo.org; Sun, 02 Nov 2008 01:29:07 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3C71BE02DF; Sun, 2 Nov 2008 01:29:06 +0000 (UTC) Received: from titan.bumpin.org (mail.bumpin.org [69.62.137.202]) by pigeon.gentoo.org (Postfix) with ESMTP id EBEB7E02DF for ; Sun, 2 Nov 2008 01:29:05 +0000 (UTC) Received: from a (barrier.bumpin.org [69.62.137.201]) by titan.bumpin.org (ESMTP) with ESMTPSA id 4C3C7897E2 for ; Sat, 1 Nov 2008 18:29:04 -0700 (PDT) From: Gordon Malm To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PMS] Add RESTRICT="distcc" capability Date: Sat, 1 Nov 2008 18:29:03 -0700 User-Agent: KMail/1.9.9 References: <200811011357.17258.gengor@gentoo.org> <200811011547.09038.gengor@gentoo.org> <490CE611.2020900@gentoo.org> In-Reply-To: <490CE611.2020900@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200811011829.03758.gengor@gentoo.org> X-Archives-Salt: e5236d04-4dd8-46aa-a34f-0a1e0dddf243 X-Archives-Hash: 64d4e8675d6af2721812e0e44766023f 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=3D"distcc". This is something to be addressed > > through developer documentation that using RESTRICT=3D"distcc" should > > be a last resort. > > Uh, RESTRICT=3Ddistcc 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: >=20 > 'It is true that RESTRICT=3D"distcc" is usually not the proper solution t= o=20 > problems.' >=20 > Parallel building problems can often and should be addressed properly. I= =20 > don't want the answer to every one that comes along to be to add=20 > RESTRICT=3D"distcc". This is something to be addressed through developer= =20 > documentation that using RESTRICT=3D"distcc" should be a last resort. You're the one assuming the only purpose would be to mask parallel make=20 problems. Apparently it does have a purpose though since avidemux builds=20 fine in parallel but NOT via distcc. Back to your most recent post > *If* there's a legitimate use for RESTRICT=3Ddistcc 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=3Ddistcc won't fix), a user > configuration issue (which RESTRICT=3Ddistcc won't fix) or a hardened > toolchain bug (for which RESTRICT=3Ddistcc 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=20 haven't pointed to any user configuration issues. Using RESTRICT=3Ddistcc = on=20 kernel modules is hardly overkill. This isn't openoffice. I know exactly= =20 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 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=C3=A1t 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=20 we can't depend on the __KERNEL__ macro for detection, how else do you=20 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=20 don't know how this will affect other ARCHes, do either of you? This could= =20 potentially get really tricky. If it can't be done nicely in the eclass fo= r=20 every possible kernel release and out-of-tree module, then we get into=20 patching *everything* and having to maintain it forward. So this is just a= =20 different workaround, a rather heavy-handed and high-maintenance one at tha= t. =20 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=20 demonstrated his anti-Hardened (and anti-Gentoo) slant on multiple occasion= s=20 define what goes in our PMS? Gordon Malm (gengor)