From owner-freebsd-questions@FreeBSD.ORG Mon Oct 31 11:42:32 2005 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 471C616A41F for ; Mon, 31 Oct 2005 11:42:32 +0000 (GMT) (envelope-from spamrefuse@yahoo.com) Received: from web36212.mail.mud.yahoo.com (web36212.mail.mud.yahoo.com [209.191.68.238]) by mx1.FreeBSD.org (Postfix) with SMTP id 9B32C43D45 for ; Mon, 31 Oct 2005 11:42:31 +0000 (GMT) (envelope-from spamrefuse@yahoo.com) Received: (qmail 57429 invoked by uid 60001); 31 Oct 2005 11:42:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VkMnmdBxUytBMH97R41tW3UBVgGDdG8HnevRZOSx9yVJ4JFbL/lv5QznyzjRkRO+kVXNrJx6ckAl0c2Lq109aaVB9dS+JZwwOy/IKKZSbzh4+tJdNZHVuX+cmeIGiRiu01QOhZZ16BF58Cd0EvylNGz5cBOTuSekOl76SAI404U= ; Message-ID: <20051031114230.57427.qmail@web36212.mail.mud.yahoo.com> Received: from [147.46.44.181] by web36212.mail.mud.yahoo.com via HTTP; Mon, 31 Oct 2005 03:42:30 PST Date: Mon, 31 Oct 2005 03:42:30 -0800 (PST) From: Rob To: Igor Robul , FreeBSD questions In-Reply-To: <4365E385.9090607@speechpro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: libXcursor.so.1.0.2 reference in libX11.so.6 ?? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2005 11:42:32 -0000 --- Igor Robul 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