Re: [gentoo-amd64] Re: x86_64 optimization patches for glibc.

[Brian Hall]

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@×××.net> wrote:

> Simon Strandman posted <42E55ADB.8030201@×××××.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@g.o mailing list