[gentoo-amd64] Re: Unexpected side effect of GCC 4

[Duncan]

Peter Humphrey <prh@××××××××××.uk> posted
200611050845.42865.prh@××××××××××.uk, excerpted below, on  Sun, 05 Nov
2006 08:45:42 +0000:

> Now that I've finally managed to build a full system using GCC 4.1.1 on the
> workstation, I find its rsync traffic has leapt to full speed with no
> collisions to speak of. I'm not complaining, mind, but this is a puzzle. As
> far as I know I haven't changed anything else - certainly the firewall box
> has been running continuously throughout.
>
> The speeds I mention are as shown by gkrellm (a very useful utility). The
> network drivers are a module on the workstation (tg3) and built-in on the
> firewall (8139too). The CFLAGS are "-O2 -march=k8 -pipe" on the firewall
> and the set offered by Duncan recently on the workstation.

What about linux-headers and glibc?  The new glibc (2.5) has had some very
strange interactions here.  See the earlier thread where I mentioned
dropping back to 2.4 for awhile.  I'll very readily admit whatever is
going on is /way/ beyond my comprehension, but 2.5 does something with
memory transfers that 2.4 apparently never did, and there's something on
my system that simply doesn't fully like it.  xmms (right before the mask,
but I removed it rather than worry about it since I knew it was being
masked anyway), kaffeine, and amarok, all three, aren't fully stable,
while kmplayer seems perfectly fine.  xmms was using a different library
set, but kaffeine, amarok, and kmplayer are using xinelib.  kmplayer
hasn't yet been rebuild and with it the only one remaining stable, I don't
want to mess with it, but I've tried rebuilding all sorts of other stuff
for the others, xinelib, qt, kdelibs, glibc, even gcc (to rebuild
libstdc++), most with several sets of cflags including plain old
-march=amd64 -pipe -O2, with nothing getting the unstable things stable or
upsetting the stability of kmplayer.  The /only/ thing that seems to get
the others stable again is reverting to glibc 2.4.  If kmplayer using the
same xinelib was also unstable, I could understand it.  If xmms using a
different decoder and /not/ using qt and kdelibs was stable, I could
understand that.  However, the particular mix and match that I have simply
doesn't make a lot of sense, and the only common thing to the set is that
reverting to glibc-2.4 magically stabilizes everything once again, even
tho in theory that's a VERY bad thing to do (and requires a bit of fancy
footwork to get portage to do at all).  Yet others report no problems at
all with the same programs and glibc 2.5.  Maybe it's a CFLAGS (or
CXXFLAGS) thing, but if it is, I've certainly not hit the elusive
dependency that's causing the issue.  glibc itself filters nearly all
cflags but -march, -pipe, and -O2, and anyway, I tried rebuilding it with
/just/ those CFLAGS/CXXFLAGS specified, and it didn't change anything.

One of these days I'll do a full emerge --emptytree, and see if that fixes
it, but meanwhile, there's a mystery that doesn't seem to match up with
anything expect for glibc 2.5, only others report no problems with the
exact same apps, so the mystery remains!  I don't like such untraceable
mysteries in my computer system!  Quite apart from any instabilities or
other issues they might trigger, I'm used to being able to ultimately
being able to point at something or some combination of somethings and say
definitively, "that is/was the problem."  It bothers me when I cannot do
so, and all is not right in my world until I /can/ do so (again, quite
apart from actually fixing the issue, just being able to point to it).

Anyway, if you are running glibc 2.5 on any of the machines, how does
the sudden return to full speed rsyncing match up with the machines with
2.5, if at all.  What about the machine with my CFLAGS?  If they are
related in any way, "enquiring minds want to know!"  =8^)  If your mystery
is glibc 2.5 related as well, well then, I'll not feel so strange as at
least there'll be two folks with a similar glibc 2.5 related mystery,
which makes it less of one already! =8^)

Of course, if you still have glibc 2.4 on everything, this won't help at
all, but at least it'll be one thing both you and I can scratch off as
relating to both of us.

-- 
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

-- 
gentoo-amd64@g.o mailing list