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

[Duncan <1i5t5.duncan@cox.net>]

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.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list