This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: glibc cvs breaks JDK Mozilla plugin


Hi Jack,

I just saw your post on libc-alpha mailing list.  My e-mail goes out via
sympatico when I am at home, but my reply to address and e-mail address are
set to khendricks@ivey.uwo.ca

You can always reach me via that address.

I will look into this.

Note, if you upgrade to any Mozilla nightly *after* M18, changes by the
Mozilla team (moving from gtk windows to x11 windows) has broken the plugin
once again.
So please stay with official M18 sources when trying to track this one down.

Blackdown already has a fix for this and the next plugin will work around
this change to provide backward capability.

I have access to the plugin source and will get my work machine back up
with a recent glibc cvs checkout on Monday and see what if anything I can
find.

That specific error message you provide means that the path for finding the
libjvm.so is messaged up in some way.  That path is determined from the
placement of the sym-link to javaplugin.so installed with the jdk.

It uses the following code snippet to find out the actual real path to the
jdk installation.  If there have been alot of changes to the dl* code then
the problem may be here somewhere.

   /* under linux the plugin comes as part of the jdk so now
       we find out the location using dladdr and from that get
       the jre home which is all we need.  this is much easier.
       Thanks to Juergen for thinking this up
    */

    Dl_info dlinfo;
    static int dummy;
    char buf[PATH_MAX];
    char real[PATH_MAX];

    // Now: Only use the JRE which came with the plugin.

    state->java_dir = NULL;
    dladdr((void *)&dummy, &dlinfo);
    strcpy(buf, dlinfo.dli_fname);

    if (realpath(buf, real) == NULL) {
        fprintf(stderr, "Error: realpath(`%s') failed.\n", buf);
        return;
    }

    *(strrchr(real, '/')) = '\0';  /* executable file      */
    *(strrchr(real, '/')) = '\0';  /* $(ARCH)             */
    *(strrchr(real, '/')) = '\0';  /* plugin              */

    state->java_dir = strdup(real);


This path info is then passed to the forked java_vm process via environment
variables.  So there could still be alot of potential problem areas other
than this but I won't know until I actually try it.

Kevin



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]