Very Computer

--NDJejMx8bV
Content-Type: text/plain; charset=us-ascii
Content-Description: message body text
Content-Transfer-Encoding: 7bit

I have been working on the plugin for Mozilla for a while, so I guess I
should post my results and maybe someone can improve on them.

The plugin compiles, with a few changes to the master Makefile in the
port.  I attach the diffs at the end of this message.  Basically, the
plugin needs to find glib12, gmodule12, gdk12, gtk12, and nspr4
libraries.  The first four come from the glib12 and gtk12 ports, so I
added LIB_DEPENDS to cover those.  nspr4 is inthe mozilla port, so I
added a dependency on mozilla to the port.  I don't mind adding the glib
and gtk dependencies, but the mozilla dependency seems like a stretch,
especially for someone who doesn't want the plugin.

Anyway, the plugin makefile cannot find the libraries directly, since it
is looking for -lglib instead of -lglib12, so I added a pre-patch set to
create a directory and place symbolic links to the actual libraries.
Then, we can merely set the appropriate make environment variables, and
the patch builds nicely.

We can solve the nspr4/mozilla problem by including a copy of the i386
nspr4 library in
j2sdk1.3.1/plugin/.oji-plugin/src/motif/lib/solaris/i386/libnspr4.so as
part of the port.  It's up to Greg.

Also, there is a false comment about needing to build images before
plugin on i386 in some makefile somewhere.  This is just wrong.  If you
don't build the plugin before images, the plugin will not be included in
the installed images.  So, I changed the all target to "all plugin
images" and everything seems to work.

If you are interested in testing, have a look at
j2sdk1.3.1/ext/plugin/oji-plugin/src/motif/Notes.  This explains how to
set up the plugin for debugging.  You need to at least set the
environment variable THREADS_FLAG=green before starting mozilla, or you
will get nowhere.  You can also set JAVA_PLUGIN_TRACE to enable the
creation of plugin trace files in /tmp named plugin_parent131.trace and
child_java_vm131.trace.  My experiments show that the child runs up to
the point of calling JNI_CreateJavaVM and dies somewhere in that
function.  Any furhter details require work with gdb.

I hope this encourages others to help inthe debugging process.

/Joe

--NDJejMx8bV
Content-Type: text/plain
Content-Description: diff
Content-Disposition: inline;
        filename="Makefile.diff"
Content-Transfer-Encoding: 7bit

--- Makefile.orig       Tue Oct 16 05:43:07 2001

                zip:${PORTSDIR}/archivers/zip \
                gtar:${PORTSDIR}/archivers/gtar \
                ${JDK13DIR}/bin/javac:${PORTSDIR}/java/linux-jdk13 \
-               ${X11BASE}/lib/libMrm.a:${PORTSDIR}/x11-toolkits/open-motif-devel
+               ${X11BASE}/lib/libMrm.a:${PORTSDIR}/x11-toolkits/open-motif-devel \
+               mozilla:$(PORTSDIR)/www/mozilla
+LIB_DEPENDS=   glib12:$(PORTSDIR)/devel/glib12 \
+               gtk12:$(PORTSDIR)/x11-toolkits/gtk12
 RUN_DEPENDS=   javavm:${PORTSDIR}/java/javavmwrapper

                SYS_CFLAGS="${CFLAGS}" \
                CLASSPATH="" \
                LD_LIBRARY_PATH="" \
-               JAVA_COMPILER=""
-ALL_TARGET=    all images
+               JAVA_COMPILER="" \
+               LIBG_HDRS=/usr/local/include/glib12 \
+               GTK_HDRS=/usr/X11R6/include/gtk12 \
+               LIBIDL_HDRS=  \
+               LIBG_LIB_DIR=${WRKDIR}/j2sdk1.3.1/ext/plugin/build/bsd \
+               GTK_LIB_DIR=${WRKDIR}/j2sdk1.3.1/ext/plugin/build/bsd \
+               LIBIDL_LIB_DIR=/usr/X11R6/lib/mozilla
+ALL_TARGET=    all plugin images
 TAR=           gtar    # Necessary for proper extraction of sources
 BSD_TAR=       /usr/bin/tar

                ${MKDIR} -p j2sdk1.3.1/ext/plugin/oji-plugin/include/bsd/jdk12 && \
                ${MKDIR} -p j2sdk1.3.1/ext/plugin/oji-plugin/include/solaris/navig5/private && \
                ${MKDIR} -p j2sdk1.3.1/src/bsd/doc/man && \
+               ${MKDIR} -p j2sdk1.3.1/ext/plugin/build/bsd && \
+               ln -s /usr/local/lib/libglib12.so j2sdk1.3.1/ext/plugin/build/bsd/libglib.so && \
+               ln -s /usr/local/lib/libgmodule12.so j2sdk1.3.1/ext/plugin/build/bsd/libgmodule.so && \
+               ln -s /usr/X11R6/lib/libgdk12.so j2sdk1.3.1/ext/plugin/build/bsd/libgdk.so && \
+               ln -s /usr/X11R6/lib/libgtk12.so j2sdk1.3.1/ext/plugin/build/bsd/libgtk.so && \
                        ${PATCH} < ${WRKDIR}/jdk131.patches

 .if !defined(NODEBUG)

--NDJejMx8bV--

with "unsubscribe freebsd-java" in the body of the message

Quote:Bill Huey writes:

nspr=NetScape mumble, mumble...essentially the netscape standard calling
sequences...

 > I wasn't sure that the plugin worked with anything other than native
 > threading. Any quick pointers to the sources for it off hand so that I
 > can look how it would interact with the JVM's threading systems
 > (native, green) ?

The plugin itself has nothing to do with threading model.
libjavaplugin_oji.so is merely a method of creating a child process
(fork) with several pipes open to the Mozilla parent for passing
requests back and forth.  The parent (Mozilla) does not actually include
a jvm in it's address space.  The child process is essentially the
executable java_vm using whatever threading model is specified by the
environment variables (THREADS_FLAG in the parent is transformed into
THREADS_TYPE for the child).  It should make no difference what thread
model is used in the child, as the only thing plugin-related is entirely
contained in
j2sdk1.3.1/ext/plugin/oji-plugin/src/motif/jvm_{exec,natives}/*, which
are used to build the executable java_vm, which is installed in the jre
lib hierarchy.

If you look at
j2sdk1.3.1/ext/plugin/oji-plugin/src/motif/jvm_exec/java_vm.c, you will
see where the plugin fails in its current state.  This is a very simple
file and only sets up the environment for the jvm to run in.  According
to my traces, it gets as far as printing the JNI_VERSION and calls the
function JNI_CreateJavaVM, but somehow fails during that function,
killing both the child and parent mozilla processes.

As far as I know, there is nothing controversial about the trace or the
processing.  It is entirely possible that I am missing something.  I
believe that the JNI_CreateJavaVM function is in libjvm.so, a standard
library.

/Joe

with "unsubscribe freebsd-java" in the body of the message

/Joe

with "unsubscribe freebsd-java" in the body of the message

Quote:> The problem with leaving the RUN_DEPENDS on mozilla is that people who
> are interested in Java may not necessarily have mozilla installed.
> -lnspr4 is only used to create the OJI version of the plugin, which
> depends on Netscape 6.x or Mozilla whatever.

Still, if you don't have Moz installed then you probably aren't
interested in building the OJI version of the plugin, so you wouldn't
need NSPR included anyway.

Quote:> In order to
> separate us from the hugeness that is mozilla, we can either depend on
> mozilla-embedded to get a slightly smaller dependency or else simply
> include libnspr4.so in the port directly.

<shugs>

Personally, I don't think either way is a problem.

Mike.

--

"Every motive escalate."
  Blatant self-promotion: <http://web.vee.net/>

with "unsubscribe freebsd-java" in the body of the message

Quote:> I have been working on the plugin for Mozilla for a while, so I guess I
> should post my results and maybe someone can improve on them.

> The plugin compiles, with a few changes to the master Makefile in the
> port.  I attach the diffs at the end of this message.  Basically, the
> plugin needs to find glib12, gmodule12, gdk12, gtk12, and nspr4
> libraries.  The first four come from the glib12 and gtk12 ports, so I
> added LIB_DEPENDS to cover those.  nspr4 is inthe mozilla port, so I
> added a dependency on mozilla to the port.  I don't mind adding the glib
> and gtk dependencies, but the mozilla dependency seems like a stretch,
> especially for someone who doesn't want the plugin.

Quote:> Anyway, the plugin makefile cannot find the libraries directly, since it
> is looking for -lglib instead of -lglib12, so I added a pre-patch set to
> create a directory and place symbolic links to the actual libraries.
> Then, we can merely set the appropriate make environment variables, and
> the patch builds nicely.

> We can solve the nspr4/mozilla problem by including a copy of the i386
> nspr4 library in
> j2sdk1.3.1/plugin/.oji-plugin/src/motif/lib/solaris/i386/libnspr4.so as
> part of the port.  It's up to Greg.

Quote:> Also, there is a false comment about needing to build images before
> plugin on i386 in some makefile somewhere.  This is just wrong.  If you
> don't build the plugin before images, the plugin will not be included in
> the installed images.  So, I changed the all target to "all plugin
> images" and everything seems to work.

Quote:> If you are interested in testing, have a look at
> j2sdk1.3.1/ext/plugin/oji-plugin/src/motif/Notes.  This explains how to
> set up the plugin for debugging.  You need to at least set the
> environment variable THREADS_FLAG=green before starting mozilla, or you
> will get nowhere.  You can also set JAVA_PLUGIN_TRACE to enable the
> creation of plugin trace files in /tmp named plugin_parent131.trace and
> child_java_vm131.trace.  My experiments show that the child runs up to
> the point of calling JNI_CreateJavaVM and dies somewhere in that
> function.  Any furhter details require work with gdb.

> I hope this encourages others to help inthe debugging process.

Thanks for working on this Joe!

--

Eyes Beyond                           Phone : (801) 765 1887
Information Technology                Web   : http://www.eyesbeyond.com

with "unsubscribe freebsd-java" in the body of the message