GNOME Bugzilla – Bug 335136
Miscompilation of glib causes maillist scrollbar in Evolution 2.6.0 to be insensitive
Last modified: 2006-05-15 12:38:03 UTC
Please describe the problem: The scrollbar that is attached to the list of available mails can not be dragged to adjust which messages are displayed. Pressing the scroll buttons either end of this scrollbar also has no effect. Workaround is to use cursor keys to navigate the list of available mails. Steps to reproduce: 1. Start evolution 2. select a folder which has more mails than can be displayed in the mail list view 3. try to scroll using the scollbar Actual results: nothing Expected results: listview gets adjusted according to scrollbar Does this happen every time? yes, reproducible every time Other information:
Can not reproduce this, WORKSFORME. Felix, what is your Desktop Environment and Theme used? GTK+ version, distro? Not sure what exactly could cause this, but I highly doubt this is an Evo issue. NEEDINFO.
I'm using GNOME 2.14.0 with Clearlooks theme. GTK+ 2.8.16 Gentoo 2006.0 I still suspect this caused by some non standard code in Evolution because all other scroll bars on my desktop (including all scroll bars in Evolution) work flawlessly. Of course, Evolution 2.4.* worked without problems... If you don't have any hint about what might be going wrong, I'll randomly downgrade stuff to get some kind of clue for you. I've filed a bug with my Distro: http://bugs.gentoo.org/show_bug.cgi?id=126921
I'm facing the same problem with Evolution 2.6 on a Sun Solaris 5.8 resp. 5.9. The packages are handmade and are on Gnome 2.12 level. The problem is independant of the theme used. Other scrollbars within Evolution do work, too. The workaround works for me, but it's quite uncomfortable. Other Gnome apps works fine. Evolution 2.4 works, too.
I have exactly the same problem. I'm also using gentoo with gnome 2.14.0, gtk+ 2.8.16 and the evolution ebuild install is marked as being 2.6.0-r1 (I had the same problem with 2.6.0) There was no problems before with evolution 2.4
I have found a lead: after recompiling gtk+ and glib (not evolution) with more conservative optimisation flags the bug went away. I'll investigate further which flags cause this misbehaviour. (Strange that only this one scrollbar in the whole system is affected!)
OK, we have a winner :-) I normally compile everything with these flags using GCC 3.4.6 (Gentoo 3.4.6-r1): -Os -fweb -frename-registers -fomit-frame-pointer -march=pentium-m Re-compiling only glib(!)version 2.10.2 without -fomit-frame-pointer fixes this bug for me. Can any of the other people experiencing this confirm? So this is probably either a bug in GCC or in glib. I'll rephrase the summary accordingly and change the affected product. It's still strange why only this one scroll bar is affected...
The fact that only one scrollbar in evolution is affected may point to ETable rather than glib. Anyway, there is not much we can do here, based on the current information. You would have to dig into what is different between the runs with the differently compiled glibs.
I've tried with and without -fomit-frame-pointer and with different libs on our SPARCS. It works with all evolution versions up to and including 2.4.2.1, it does not work with evolution 2.6.0 and 2.6.1. I would also think that the problem lies withing evolution ETable, but did not have the time yet to dig deeper.
In any case, not a glib problem, more of a gentoo problem.
Neither a glib nor a gentoo problem. I'm running it on some Sun Sparc-Servers with Solaris 5.8/5.9/5.10. Probably a bad interaction between some supporting libraries?