Bug 179044
Summary: | Mouse pointer theme not activating correctly | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Garry Harthill <gazzerh> | ||||
Component: | libX11 | Assignee: | Christopher Aillon <caillon> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | |||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | dcantrell, suckfish, umar, xgl-maint | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i386 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2006-02-23 21:58:42 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 150221 | ||||||
Attachments: |
|
Description
Garry Harthill
2006-01-26 20:32:47 UTC
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 |