Date: Fri, 28 Oct 2005 01:20:40 -0700 (PDT) From: Rob <spamrefuse@yahoo.com> To: Eric Anholt <eta@lclark.edu> Cc: freebsd-x11@freebsd.org Subject: Re: libXcursor.so.1.0.2 reference in libX11.so.6 ?? Message-ID: <20051028082040.17501.qmail@web36206.mail.mud.yahoo.com> In-Reply-To: <1130485803.1034.89.camel@leguin>
next in thread | previous in thread | raw e-mail | index | archive | help
--- Eric Anholt <eta@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051028082040.17501.qmail>