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 <[EMAIL PROTECTED]> wrote: > Simon Strandman posted <[EMAIL PROTECTED]>, 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. -- [email protected] mailing list
