From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060103 Fedora/1.5-4 Firefox/1.5
Description of problem:
It seems if i change the to bluecurve cursor theme using System -> Prefs -> Mouse it seems to change the settings in the current active window only. All others are the same old cursors. Although the cursors work in the active window only the hour glass cursor is still not showing. If I swap to another active window the theme doesn't follow. It only works in the active window the theme was activated in.
If i change the cursor theme with all active windows closed the theme doesn't change the cursors at all.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Load into Gnome. Mine is in initlevel 5 so it goes straigt in.
2. Change theme using System -> Prefs -> Mouse to Bluecurve
Actual Results: I can see the animated cursor just before GDM runs. It then changes to the unanimated cursor when GDM actually starts.
When logged into Gnome theme is not the bluecurve theme which it should be. When the theme is changed note that change only works in active window. Mouse over the panel at top or bottom or over another program and the mouse changes to the default theme
Expected Results: Theme should be active when GDM is run and when Gnome loads. It should also be active in all aspects of the running of Gnome and not just in the active window.
I can't reproduce.
It would be wrong for gdm to pick up your cursor theme anyway, because gdm is
not running in your session.
Is gnome-settings-daemon running ?
Is this a stock gnome session, or do you something like a .Xclients or .xinitrc ?
Yes. gnome-setting-daemon is running.
This is a stock gnome session. I originally posted on the fedora-devel list. Two
other people also experience the same problem.
attached is a strace requrested for gnome-calculator which will not show the
cursor arrow set as the gheme.
Created attachment 123748 [details]
All I can see about cursors is the inability to find libXcursor.so. I have
libXcursor installed, but it doesn't seem to provide a .so, just a .so.1.0.2
Do you need any more information from me? I have installed on another machine
here with the same issue. It must be a bug - this other machine had the problem
from a fresh fc5t2 installation.
Jesse, thats fine. The .so is in the -devel package. It is a problem if the
library is not found, of course.
Jakub claims that glibc won't go looking for the .so (without .1) unless
somebody is dlopening it. Can you break on dlopen and see if thats the case ?
Jesse, just to make sure that we are looking at the source of the problem, can
you see if installing libXcursor-devel fixes it ?
Installing libXcursor-devel has fixed the problem for me. This ideally needs to
be included in the gnome group because it wasn't installed when I did a standard
No, thats not a fix, just a workaround.
We still need to get to the bottom of why something needs the .so instead of the
I have a similar problem:
If you run a i386 application on a x86_64 system, none of the cursor themes
work for them, while they are working fine for all x86_64 applications.
Of course the reason for running i386 applications are for plugins and codecs.
Anyway, I wonder if the missing /usr/lib/libXcursor.so (since on x86_64 we
only install the 64 bit devel package, while the I have both versions of the
libXcursor package). I am at home for the weekend so don't have access to my
x86_64 system to test.
libXcursor-devel fixed this for me also.
(In reply to comment #8)
> Installing libXcursor-devel has fixed the problem for me. This ideally needs to
> be included in the gnome group because it wasn't installed when I did a standard
That is a development package only, and should not ever be required on any
system, except for the purpose of compiling software that links to libXcursor.
If installing libXcursor-devel has the effect of making the described problem
go away, that helps in diagnosing the problem, but it is definitely not
a solution to the problem.
The next step, is to determine _why_ the problem goes away when this happens.
It appears that something has linked to libXcursor, and has a DT_NEEDED
on libXcursor.so, or is dlopening it or some other case which results in
a direct dependency on the .so.
The real solution, is fixing whatever is causing this problem, to properly
link/load libXcursor.so.* instead of libXcursor.so, in which case the
-devel package should no longer be needed to work around the underlying
I'm going to investigate the libXcursor package now, to see if the bug
is actually in libXcursor.so.* itself, which is theoretically possible,
as there was a problem of a similar but slightly different nature in
libXaw.so.* during X11R7 beta testing which was resolved in the final
I'll update the report once I've analyzed the libXcursor runtime.
Grepping the X sources appears to show the culprit:
./X11/src/CrGlCur.c:56:#define LIBXCURSOR "libXcursor.so"
./Xcursor/include/X11/Xcursor/Xcursor.h-432- * This is the function called by
Xlib when attempting to
./Xcursor/include/X11/Xcursor/Xcursor.h-433- * load cursors from
XCreateGlyphCursor. The interface must
./Xcursor/include/X11/Xcursor/Xcursor.h:434: * not change as Xlib loads
'libXcursor.so' instead of
./Xcursor/include/X11/Xcursor/Xcursor.h-435- * a specific major version
Thanks for the info, I'll reassign it to libXcursor for now.
I can also confirm that the problem mentioned in comment #10, running i386
applications on x86_64, is also solved if I install the i386 devel package,
which should not be installed!
Mike, any progress on this ? Can't we just dlopen libXcursor.so.1 ? Or even link
against it ?
This issue is high visibility and the potential risk here for this fix seems
minimal. Matthias and I think this should be moved to the FC5Blocker list as
this makes us look silly, and there's no reason a standard install should
require a -devel package.
A blocker is something that will block the release of the OS, holding it
back until it is fixed. This is definitely not a blocker. Moving to
Fixed in libX11-1.0.0-3