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): How reproducible: Always 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. Additional info:
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] strace 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 and so.1
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 installation.
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 .so.1
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 > installation. 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 issue. 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 release. 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-54- ./X11/src/CrGlCur.c-55-#ifndef LIBXCURSOR ./X11/src/CrGlCur.c:56:#define LIBXCURSOR "libXcursor.so" ./X11/src/CrGlCur.c-57-#endif ./X11/src/CrGlCur.c-58- -- ./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 ./Xcursor/include/X11/Xcursor/Xcursor.h-436- */
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 FC5Target.
Fixed in libX11-1.0.0-3