From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1FzBNS-0003S8-Q7 for garchives@archives.gentoo.org; Sat, 08 Jul 2006 11:53:39 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.7/8.13.6) with SMTP id k68BqeCH018326; Sat, 8 Jul 2006 11:52:40 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.13.7/8.13.6) with ESMTP id k68BnEtN007951 for ; Sat, 8 Jul 2006 11:49:14 GMT Received: from gentoo.org (cp237988-a.mill1.nb.home.nl [84.29.235.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 3AD9F64934 for ; Sat, 8 Jul 2006 11:49:13 +0000 (UTC) Date: Sat, 8 Jul 2006 13:51:32 +0200 From: Harald van =?utf-8?Q?D=C4=B3k?= To: gentoo-dev@lists.gentoo.org Subject: Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags) Message-ID: <20060708115132.GA5578@gentoo.org> References: <200607061252.33028@enterprise.flameeyes.is-a-geek.org> <200607071813.28005.vapier@gentoo.org> <20060707230445.GA3800@gentoo.org> <200607071950.28503.vapier@gentoo.org> <20060708062035.GA3903@gentoo.org> <1152350877.9384.100.camel@lycan.lan> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1152350877.9384.100.camel@lycan.lan> User-Agent: Mutt/1.5.11 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by robin.gentoo.org id k68BqeE5018326 X-Archives-Salt: 21bb29ae-5709-4c11-b19b-e8fa90e41b82 X-Archives-Hash: 781dc07b7ec032a54375034cc955b54d On Sat, Jul 08, 2006 at 11:27:57AM +0200, Martin Schlemmer wrote: > On Sat, 2006-07-08 at 08:20 +0200, Harald van D=C4=B3k wrote: > > On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote: > > > On Friday 07 July 2006 19:04, Harald van D=C4=B3k wrote: >=20 > > > the ssp/pie/htb patches have their own USE flags so separating them= from=20 > > > USE=3Dvanilla makes perfect sense ... > >=20 > > I'm not disagreeing with that, but removing an older option is not ju= st > > providing more choices. > >=20 > > > now you can do: > > > gentoo patches + ssp > > > gentoo patches + nossp > > > vanilla + ssp > > > vanilla + nossp > >=20 > > gentoo patches + ssp > > gentoo patches + stub > > vanilla + ssp > > vanilla + stub > >=20 > > > whereas before you only had the option of: > > > gentoo patches + ssp > > > vanilla + nossp > >=20 > > gentoo patches + ssp > > gentoo patches + stub > > vanilla > >=20 > > > like i said in my previous e-mail, forcing stubs onto people even w= hen=20 > > > USE=3Dvanilla *is by design* because i got tired of people who had = no clue=20 > > > about the consequences throwing USE=3Dvanilla into their USE in mak= e.conf and=20 > > > then complaining when the lack of SSP broke things ... > >=20 > > But I'm not asking for USE=3D"vanilla" to disable SSP completely, I'm= only > > asking for USE=3D"vanilla nossp" to disable it. "nossp" is already > > explicitly documented as "NOT FOR GENERAL USE", too. > >=20 >=20 > No offence, but you are being very unreasonable in this thread. The > fact that you can get what you are after, even though its not entirely > supported, should be enough for you, especially for the fact that you > are not clueless. >=20 > You should remember that somebody at the end of the day have to > sacrifice time and effort to fix bugs, and especially with something as > complex as gcc, the more variables, the more effort it is going to be. > And as Mike is relatively the only person currently who seems to > maintain gcc, it should be his prerogative to decided that he get too > much spam without the stubs. Sorry, but how much mail he gets does not affect one bit which behaviour is better, it only helps understand why the lesser behaviour could be chosen by reasonable people anyway. (Regardless of which behaviour is the lesser one.) And I don't harass anyone about -- it's been a very long time since I even mentioned any problems like this, and if nothing is done after this thread dies, I'll likely be quiet about it for a long time again -- so please don't act like I do. > And you should really know by now that being documented as "NOT FOR > GENERAL USE" will still not stop more than enough users to waste his > time in telling them not to disable SSP with vanilla if they don't know > what they are doing. I guess that's a fair point. > > Gentoo's gcc with the vanilla flag isn't the official GCC. Most patch= es > > don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported > > compiler in Gentoo. >=20 > For the fact that we do not support vanilla gcc - I assume this is a gc= c > built by yourself - Actually, I meant gcc built with the vanilla flag here, as opposed to pure official GCC, which I already stated is unsupported earlier. > this truly is really unfair of you to expect it. > The 'contract' we usually have with upstream, is that if we apply > patches to their software, we will be the first tier in the support > chain. Now you want to run gcc which was not modified by us to fix the > known hangups in how we do things - or save us time for that matter, an= d > you still want us to support it - or at least make life easier for us b= y > not leaving gaping holes that cost us maintenance time? Differences between official GCC and Gentoo's GCC are 1) fixed bugs, and 2) added features. (Assuming no patches are broken.) I think it's reasonable to not rely on the existence of those added features. You seem to think I think it's reasonable to not rely on bugs being fixed. No problem there, I don't. Besides, I said it's unfortunate that vanilla GCC (either one) is unsupported, not that it must be. My other problem, that vanilla GCC is different from Gentoo's GCC with the vanilla flag (plus maybe nossp/nopie/...), can be handled without requiring support for it from anyone. > Am I the only one feeling that this is really selfish/absurd thinking > since you have such an hackle in what we do, to not research, debug, an= d > file thus your own bugs with http://gcc.gnu.org/bugzilla/ ? I actually do file bugs there when I run into them. > The alternative to this that you seem to ignore, is that you can start > helping maintaining gcc (I am sure Mike will appreciate help with > Halcy0n gone as well, and me not having that much time currently). Since I'm more interested in vanilla GCC, I think there's little to help maintain from Gentoo's side (support in ebuilds, and possibly the build process, that's it). If that's something you think help would be good for anyway, though, sure, if I can. > And > of course promising so long as the stubs do not get applied with nossp, > that you will handle all breakage in that area. I have no problems modifying ebuilds / packages to autodetect flags instead of assuming they exist myself, if it means vanilla GCC will be supported feature-wise, for those versions of which the corresponding Gentoo-patched version is supported. > Although I do not know > if its still really fair to expect Jakub et ell to sacrifice time to > process the bugs, and get them to you if its related to something > failing due to the missing stubs. I /could/ read toolchain@ mail if I would help out with GCC, you know, which is where such bugs should end up going to currently (those not closed as dupes) if the package maintainer thinks it's a bug that some GCC version doesn't support a particular flag. :) Or am I misunderstanding? --=20 gentoo-dev@gentoo.org mailing list