math/grace port: "libXcursor.so.1.0" not found ??

Rob wrote:

>-----------------------------------
>   XtAppContext app_con;
>   Display *disp = NULL;
>   char *display_name = NULL;
>
>   XtSetLanguageProc(NULL, NULL, NULL); 
>   XtToolkitInitialize();
>   app_con = XtCreateApplicationContext();
>
>   disp = XOpenDisplay(display_name);
>-----------------------------------
>
>(I have simplified this code snippet a bit, for
>this example; also, grace uses Motif for its GUI).
>
>Before the XOpenDisplay() call, dlerror() does
>not have the error-indicator set, but after
>that call, it has.
>
>Is this where Linux and FreeBSD are out-of-sync?
>Or does Grace something wrong here, or is this
>a problem cause by FreeBSD or Xorg?
>
>  
>
I think, that when XOpenDisplay called, ld.so tries load
some libraries 
from preconfigured paths, and
last unsuccessful attempt is recorded for dlerror().

dlopen() _does not_ reset dlerror() state on sucess, it just
returns non 
NULL. So you must not check dlerror() for error condition,
you need 
check return result of dlopen(), and if it is NULL, then you
need use 
dlerror().

So, code in grace:

   dlopen("library name", MODE);
   if (dlerror() != NULL) {
      report_error();
      exit(1);


   }


need to be:

handle = dlopen("library name", MODE);
if (handle == NULL) {  
        report_error(dlerror());

      exit(1);

}

just because dlerror() != NULL is not indicator of error.
_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

Igor Robul wrote:

> dlopen() _does not_ reset dlerror() state on sucess, it
just returns 
> non NULL. So you must not check dlerror() for error
condition, you 
> need check return result of dlopen(), and if it is
NULL, then you need 
> use dlerror().
>
> So, code in grace:
>
>   dlopen("library name", MODE);
>   if (dlerror() != NULL) {
>      report_error();
>      exit(1);
>
Actual code in grace is:

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

But I think it is needed to be something like (I dont know
if they need 
"error" variable later):

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


_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

Sorry,
I have reread manual page for dlerror() and found that it
need clear 
error state after call, but
dlerror() in src/libc/gen/dlfcn.c does not do this:

#pragma weak dlerror
const char *
dlerror(void)
{
    return sorry;
}

So error is in FreeBSD libc, if I understand this correctly.
I'll do PR.

_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

Igor Robul wrote:

> Sorry,
> I have reread manual page for dlerror() and found that
it need clear 
> error state after call, but
> dlerror() in src/libc/gen/dlfcn.c does not do this:
>
> #pragma weak dlerror
> const char *
> dlerror(void)
> {
>    return sorry;
> }
>
> So error is in FreeBSD libc, if I understand this
correctly. I'll do PR.

Bad day for me :-(.

Above code is from src/libc/gen/dlfcn.c, but real dlerror
for dynamicaly 
linked executables is in rtdl.c, and it works as described
in  manual 
page (clears error status).

So problem is somewhere else. Sorry for false info.

_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

--- Igor Robul <igorrspeechpro.com> wrote:

> Rob wrote:
> 
> >-----------------------------------
> >   XtAppContext app_con;
> >   Display *disp = NULL;
> >   char *display_name = NULL;
> >
> >   XtSetLanguageProc(NULL, NULL, NULL); 
> >   XtToolkitInitialize();
> >   app_con = XtCreateApplicationContext();
> >
> >   disp = XOpenDisplay(display_name);
> >-----------------------------------
> >
> >(I have simplified this code snippet a bit, for
> >this example; also, grace uses Motif for its GUI).
> >
> >Before the XOpenDisplay() call, dlerror() does
> >not have the error-indicator set, but after
> >that call, it has.
> >
> >Is this where Linux and FreeBSD are out-of-sync?
> >Or does Grace something wrong here, or is this
> >a problem cause by FreeBSD or Xorg?
>
> I think, that when XOpenDisplay called, ld.so tries
> load some libraries 
> from preconfigured paths, and
> last unsuccessful attempt is recorded for dlerror().

Here is the two points response from the grace
mailinglist:


1. Because XOpenDisplay() causes dlerror() to be
   set:
   One of the FreeBSD X libraries is broken,
   calling an inexisting libXcursor.so.1.0.

2. The FreeBSD dynamic loader is broken, ignoring
   unresolved references in DLLs both at
   initialization and run time.


So is the libX11.so.6 on FreeBSD (or another) to be
blamed?

Or is something more fundamentally wrong with
FreeBSD?

Rob.



		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

On Thu, Oct 27, 2005 at 04:00:55AM -0700, Rob wrote:

> Here is the two points response from the grace
> mailinglist:
> 
> 
> 1. Because XOpenDisplay() causes dlerror() to be
>    set:
>    One of the FreeBSD X libraries is broken,
>    calling an inexisting libXcursor.so.1.0.
> 
> 2. The FreeBSD dynamic loader is broken, ignoring
>    unresolved references in DLLs both at
>    initialization and run time.
> 
> 
> So is the libX11.so.6 on FreeBSD (or another) to be
> blamed?

Talk to the xorg maintainers (x11FreeBSD.org).  I suspect
there are
two problems: the libXcursor.so.1.0.2 reference in the x
library,
which should not be there, and a bug in xmgrace for not
correctly
handling dlerror(), as Igor has been explaining.  xmgrace
should be
robust enough to handle the case of some other application
having
failed to dlopen() something, instead of assuming it has
perfect
knowledge of the program state.

Kris