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.43) id 1DzFFe-0005FI-AU for garchives@archives.gentoo.org; Sun, 31 Jul 2005 14:57:18 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j6VEu0SC008208; Sun, 31 Jul 2005 14:56:00 GMT Received: from krusty.pcisys.net (krusty.pcisys.net [216.229.32.178]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j6VEtx0B010833 for ; Sun, 31 Jul 2005 14:56:00 GMT Received: from zippy (dsl-206-53-29-122.cos.pcisys.net [206.53.29.122]) by krusty.pcisys.net (8.13.3/8.13.3) with SMTP id j6VEtwbT009353 for ; Sun, 31 Jul 2005 08:55:58 -0600 (MDT) Received: by zippy (sSMTP sendmail emulation); Sun, 31 Jul 2005 08:56:00 -0600 Date: Sun, 31 Jul 2005 08:56:00 -0600 From: Brian Hall To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Re: x86_64 optimization patches for glibc. Message-Id: <20050731085600.65fc8657.brihall@pcisys.net> In-Reply-To: References: <42E258A7.5080501@telia.com> <1122322081.12747.5.camel@cloud.outersquare.org> <42E55ADB.8030201@telia.com> X-Mailer: Sylpheed version 2.0.0rc (GTK+ 2.6.8; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 750765b1-da4b-4721-8c80-46c46a546ad7 X-Archives-Hash: f12d8393a16fd2a62af8445ed8293811 Perhaps a USE flag could be created to enable the glibc patches, then a emerge --newuse could recompile glibc and the problem apps (or everything); maybe a mini-howto document would also be helpful. I would certainly like an easy way to enable any "free" performance boost I can get! On Sun, 31 Jul 2005 07:24:55 -0700 Duncan <1i5t5.duncan@cox.net> wrote: > Simon Strandman posted <42E55ADB.8030201@telia.com>, excerpted > below, on Mon, 25 Jul 2005 23:34:19 +0200: > > > Done! Bug #100289 > > http://bugs.gentoo.org/show_bug.cgi?id=100289 > > > > Tell me if I need to provide any more information. > > For those following the thread here, but not keeping up with the bug, > testing reveals that at least one app, nano, crashes (when searching), > with the patches applied to glibc, until nano is remerged against the > new glibc. Yes, that means that the issue goes away with a remerge, > but there could be other apps similarly affected. > > There are two factors making this *VERY* serious. (1) nano just > happens to be the text editor used in the config file editing > examples in the installation handbook, so there are likely more > Gentoo users for that particular app than in the normal Linux using > population. (2) The crash /can/ mean it eats the file it was > editing. > > Taken together, that makes the issue a critical one indeed, > particularly since the users that are still using nano rather than > having formed their own preferences (ignoring for the moment those > that have actually made an informed decision to use nano, having > tried other editors), are also likely the ones not to have backups of > their critical config files. > > Additionally, where there's app crashing due to a change in glibc, > there are bound to be more. Thus, integration of the patches is on > hold for now, and likely will be for some time, until something a bit > safer, either in strategy or in patches, can be devised. > > Thus, anyone hoping to run these in an official Gentoo glibc should be > preparing to do their own glibc patching, with each new version, for > awhile. Additionally, it could blacklist any further bugs you file, > at least until your whole toolchain and any misbehaving apps have been > remerged against the patched glibc. > > Do note that any issues that might exist would seem to disappear once > the entire system is compiled against the patched glibc. That's why > SuSE can get away with running the patch -- their entire amd64 > release will have been compiled against the patched glibc. Thus, > there are no known issues with doing a stage-1 bootstrap with these > patches, since by the time the system is up and running, it'll all be > compiled against the patched glibc. Likewise, there are no known > issues at this time, should one decide to patch glibc, and then do an > emerge --emptytree. In any case, however, doing your own glibc > patching, regardless of what the patch is, is likely to blacklist any > bugs you may file. That's something that may be worthwhile to keep > in mind. -- gentoo-amd64@gentoo.org mailing list