Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: x86_64 optimization patches for glibc.
Date: Sun, 31 Jul 2005 14:26:59
Message-Id: pan.2005.07.31.14.24.54.979639@cox.net
In Reply to: Re: [gentoo-amd64] x86_64 optimization patches for glibc. by Simon Strandman
1 Simon Strandman posted <42E55ADB.8030201@×××××.com>, excerpted below, on
2 Mon, 25 Jul 2005 23:34:19 +0200:
3
4 > Done! Bug #100289
5 > http://bugs.gentoo.org/show_bug.cgi?id=100289
6 >
7 > Tell me if I need to provide any more information.
8
9 For those following the thread here, but not keeping up with the bug,
10 testing reveals that at least one app, nano, crashes (when searching),
11 with the patches applied to glibc, until nano is remerged against the new
12 glibc. Yes, that means that the issue goes away with a remerge, but there
13 could be other apps similarly affected.
14
15 There are two factors making this *VERY* serious. (1) nano just
16 happens to be the text editor used in the config file editing examples in
17 the installation handbook, so there are likely more Gentoo users for that
18 particular app than in the normal Linux using population. (2) The crash
19 /can/ mean it eats the file it was editing.
20
21 Taken together, that makes the issue a critical one indeed, particularly
22 since the users that are still using nano rather than having formed their
23 own preferences (ignoring for the moment those that have actually made an
24 informed decision to use nano, having tried other editors), are also
25 likely the ones not to have backups of their critical config files.
26
27 Additionally, where there's app crashing due to a change in glibc, there
28 are bound to be more. Thus, integration of the patches is on hold for
29 now, and likely will be for some time, until something a bit safer, either
30 in strategy or in patches, can be devised.
31
32 Thus, anyone hoping to run these in an official Gentoo glibc should be
33 preparing to do their own glibc patching, with each new version, for
34 awhile. Additionally, it could blacklist any further bugs you file, at
35 least until your whole toolchain and any misbehaving apps have been
36 remerged against the patched glibc.
37
38 Do note that any issues that might exist would seem to disappear once the
39 entire system is compiled against the patched glibc. That's why SuSE can
40 get away with running the patch -- their entire amd64 release will have
41 been compiled against the patched glibc. Thus, there are no known issues
42 with doing a stage-1 bootstrap with these patches, since by the time the
43 system is up and running, it'll all be compiled against the patched glibc.
44 Likewise, there are no known issues at this time, should one decide to
45 patch glibc, and then do an emerge --emptytree. In any case, however,
46 doing your own glibc patching, regardless of what the patch is, is likely
47 to blacklist any bugs you may file. That's something that may be
48 worthwhile to keep in mind.
49
50 --
51 Duncan - List replies preferred. No HTML msgs.
52 "Every nonfree program has a lord, a master --
53 and if you use the program, he is your master." Richard Stallman in
54 http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html
55
56
57 --
58 gentoo-amd64@g.o mailing list

Replies

Subject Author
Re: [gentoo-amd64] Re: x86_64 optimization patches for glibc. Brian Hall <brihall@××××××.net>
Re: [gentoo-amd64] Re: x86_64 optimization patches for glibc. Simon Strandman <simon.strandman@×××××.com>
Re: [gentoo-amd64] Re: x86_64 optimization patches for glibc. Jan Jitse Venselaar <janjitse@×××××.com>