libXcursor.so.1.0.2 reference in libX11.so.6 ??

Rob spamrefuse at yahoo.com
Fri Oct 28 01:20:42 PDT 2005



--- Eric Anholt <eta at lclark.edu> wrote:

> On Thu, 2005-10-27 at 23:25 -0700, Rob wrote:
> > Hi,
> > 
> > I'm mailing to this list, after a long discussion
> > on the FreeBSD-questions list:
> >
>
http://lists.freebsd.org/pipermail/freebsd-questions/2005-October/102547.html
> > 
> > 
> > Eventually, Kris Kennaway suggested that this
> > is partially a problem caused by the X11 library:
> >
>
http://lists.freebsd.org/pipermail/freebsd-questions/2005-October/102678.html
> > 
> > The problem in a nutshell:
> > 
> > Some X11 calls, e.g. XDisplayOpen(), set the error
> > indicator in dlerror(); the error says that a
> > shared object "libXcursor.so.1.0" is not found.
> > 
> > >From 'strings /usr/X11R6/lib/libX11.so.6', there
> > appears output "libXcursor.so.1.0.2".
> > Probably there is something wrong with the X11
> > libraries and the linked objects in there.
> > 
> > Does anybody have clue on this isse?
> 
> This appears to be a bug in the app.

The Grace issue is more or less closed by now
(see below for an adequate patch).

However, since Kris Kennaway also mentioned the
possibility of a underlying/hidden bug in the
X11 library, I communicated the problem here.

The key issue here on this X11 mailinglist should
be to find out why there is a wrong reference to
libXcursor in the command:
'strings /usr/X11R6/lib/libX11.so.6' ??


> It's attempting to use dlerror to check if the
> previous dlsym() call failed, rather than
> checking if the dlsym returned NULL.
> libX11 is doing just fine, but a side effect of
> its eventually-successful dlopen()ing of
> libXcursor is that it will have caused a dlopen
> error, so dlerror() will be returning non-NULL
> for the next person that comes along.
> 
> Attached is an untested patch.

In an earlier stage, I already have communicated
this patch to the developer of Grace, but according
to him this is not acceptable, as he wrote to the
grace mailinglist -- his reference is the Linux
version of dlsym(), apparently not FreeBSD :(.
Here is what he wrote:

 "Since the value of the symbol could actually be
  NULL (so that a NULL return from dlsym() need
  not indicate an error), the correct way to test
  for an error is to call dlerror() to clear any
  old error conditions, then call dlsym(), and
  then call dlerror() again, saving its return
  value into a variable, and check whether this
  saved value is not NULL."

Therefore a better, and acceptable, patch is to
insert a kind of 'dummy' call to dlerror() prior
to the dlsym() call; this will reset any previous
error condition, before calling dlsym(); then check
the dlerror() again after the dlsym() call.
(Remember that a dlerror() call resets the error
condition!) The patch becomes something like this:

 dlerror();
 newkey.data = dlsym(handle, dl_function);
 if ((error = (char *) dlerror()) != NULL) {
    errmsg(error);
    dlclose(handle);
    return RETURN_FAILURE;
 }


As I said before, this patch more or less
closes the issue of Grace. The patch should be
accepted into the Grace sources, or otherwise
be added as a patch file to the grace port of
FreeBSD. I don't know yet what's going to happen.

Regards,
Rob.



	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com


More information about the freebsd-x11 mailing list