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

[Rob]

--- Igor Robul <igorr at speechpro.com> wrote:

> Rob wrote:
> 
> >See here:
>
>http://cvs.freedesktop.org/xorg/xc/lib/X11/CrGlCur.c?rev=1.3&view=markup
> >
> >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
> >  
> >
> If you do "find . -type f -exec grep LIBXCURSOR {}
> \; -print" in 
> extracted xorg-libraries port directory, then you'll
> find:
> #define LIBXCURSOR "Xcursor.dll"
> #ifndef LIBXCURSOR
> #define LIBXCURSOR "libXcursor.so"
> static char libraryName[] = LIBXCURSOR;
> ./lib/X11/CrGlCur.c
> XCURSOR_DEFINES = -DUSE_DYNAMIC_XCURSOR 
> -DLIBXCURSOR=\"libXcursor.so.$(SOXCURSORREV)\"
> ./lib/X11/Imakefile
> XCURSOR_DEFINES = -DUSE_DYNAMIC_XCURSOR 
> -DLIBXCURSOR=\"libXcursor.so.$(SOXCURSORREV)\"
> ./lib/X11/Imakefile.orig
> Binary file ./lib/X11/.CrGlCur.c.swp matches
> ./lib/X11/.CrGlCur.c.swp
> XCURSOR_DEFINES = -DUSE_DYNAMIC_XCURSOR 
> -DLIBXCURSOR=\"libXcursor.so.$(SOXCURSORREV)\"
> ./lib/X11/Makefile
> ^C
> 
> So we need find SOXCURSORREV value:
> 
> find . -type f -exec grep SOXCURSORREV {} \; -print
> 
> ./lib/Xcursor/Makefile
> SOXCURSORREV = 1.0.2
> ./lib/Xext/Makefile
> SOXCURSORREV = 1.0.2
> ./lib/Xrender/Makefile
> SOXCURSORREV = 1.0.2
> ./lib/dpstk/Makefile
> SOXCURSORREV = 1.0.2
> ./lib/Xpm/Makefile
> SOXCURSORREV = 1.0.2
> 
> 
> and so on.
> 
> So you can see, from where we got 1.0.2
> 


Yes, indeed, very true.
It's Xorg that has this library version hardcoded.

Meanwhile, I also found out following:

On FreeBSD, the dl* functions do not reset a
previous error indicator. In this specific case,
in xc/lib/X11/CrGlCur.c Xorg will first try to
"dlopen" the library libXcursor.so.1.0.2 without
success (this will set the dlerror indicator),
next Xorg will try to dlopen libXcursor.so.1.0
without success (again sets dlerror indicator), but
eventually successfully dlopens libXcursor.so.1.
However, the last successful dlopen call does NOT
clear the earlier dlerror indicator.

Then, when grace succesfully calls dlopen() and
dlsym(), and checks dlerror(), it will find the
old dlerror of Xorg, which failed to dlopen
libXcursor.so.1.0.

It seems that some other OSes (Linux?) actually do
clear the dlerror indicator with a succesful
dlopen() and dlsym() call. That's why the behaviour
is different there.

Conclusively:
The whole library problem boils down to the
behaviour of the dl* functions, with respect to
the clearing/setting the dlerror indicator.
In general, one should always call dlerror() prior
to the use of the dl* functions, to clear any
previous dlerror indicator:

   dlerror(); /* clear previous error*/

   handle = dlopen("blabla.lib", RTLD_LAZY)
   if ( !handle ) {
      error_print(dlerror());
      return FAILURE;
   }

   data = dlsym(....);
   error = dlerror();
   if ( !data && error != NULL ) {
      error_print(error);
      return FAILURE;
   }

   etc. etc.

Note that a dlerror() call always will clear any
previous dlerror indicator.

Does all that make sense to you?

Regards,
Rob.



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