libXcursor.so.1.0.2 reference in libX11.so.6 ??
spamrefuse at yahoo.com
Sat Oct 29 01:36:09 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:
> > Eventually, Kris Kennaway suggested that this
> > is partially a problem caused by the X11 library:
> > 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. It is
> attempting to use dlerror to check if the
> previous dlsym() call failed, rather than
> checking if the dlsym returned NULL.
Yes, that was indeed a problem with the app. too,
and a fix has been accepted by the app. developer.
> 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.
Well, my point is that there is also something
not quite right with X11 and/or with FreeBSD:
The open_library() call is the source of the
confusion. First, it tries loading
libXcursor.so.1.0.2 (why it's hardcoded in FreeBSD
remains a mistery) and fails, then libXcursor.so.1.0
and fails again, and finally succeeds with
libXcursor.so.1, but the error from the previous
failed attempt (libXcursor.so.1.0) remains uncleared.
Sounds like a not-so-clean implementation of
versioned module loader...
What do you think of this analysis?
Yahoo! FareChase: Search multiple travel sites in one click.
More information about the freebsd-x11