Re: RFA: enable gappletviewer, gjarsigner and gkeytool tools

[Bryce McKinlay <mckinlay at redhat dot com>]

Thomas Fitzsimmons wrote:
> Thomas Fitzsimmons wrote:
> > Hi,
> >
> > This patch enables the gappletviewer, gjarsigner and gkeytool tools.  
> > These tool binaries dlopen the new libjvm.so library, using the 
> > libgcj's imported libltdl.
> >
> > For now I've hard-coded the full path to libjvm.so in the dlopen 
> > call.  If the install tree is relocated, these tools will cease to 
> > work.  I've filed a general bug report for this, since there are 
> > already other places in libgcj where we hard-code full paths:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28175
> >
> > I think the relocation work should be done as a separate patch though.
>
> Here's an updated version of the patch that builds on Darwin.  It uses 
> lt_dlopenext in place of lt_dlopen and doesn't hard-code libjvm's file 
> extension.  The tools still do not work on Darwin due to some 
> Darwin-specific dlopen/dlsym issues, but those can be fixed in a 
> separate patch (hopefully by someone who understands Darwin's linkage 
> tools).
>
> Please review,
>
> Tom
>
> 2006-06-28  Thomas Fitzsimmons  <fitzsim@redhat.com>
>
>     * classpath/tools/toolwrapper.c: dlopen libjvm.so.
>     * classpath/tools/Makefile.am: Comment out binary wrapper build
>     logic.  Rename tools.zip libgcj-tools-$(gcc_version).jar and
>     install in jardir.
>     * classpath/tools/Makefile.in: Regenerate.
>     * classpath/tools/jarsigner.in: Rename ...
>     * classpath/tools/gjarsigner.in: New file.
>     * classpath/tools/keytool.in: Rename ...
>     * classpath/tools/gkeytool.in: New file.
>     * classpath/tools/appletviewer.in: Rename ...
>     * classpath/tools/gappletviewer.in: New file.
>     * classpath/configure.ac: Rename tool wrapper scripts.
>     * classpath/configure: Regenerate.
>     * classpath/Makefile.am (SUBDIRS, DIST_SUBDIRS): Add tools.
>     * classpath/Makefile.in: Regenerate.
>     * classpath/aclocal.m4: Regenerate.
>     * Makefile.am (bin_PROGRAMS): Add gappletviewer, gjarsigner and
>     gkeytool.
>     * Makefile.in: Regenerate.

I think it would be better to write a CNI toolwrapper and link it 
directly against a compiled libgcj-tools.so. This would have several 
advantages:

a) There's no need to dlopen anything, thus the wrapper code becomes 
much simpler and there is no "relocatable tree" problem.
b) The tools will work out-of-the-box on platforms that may not support 
JNI / JNI invocation for whatever reason (win32?)
c) Native compiled code will be used automatically, no need for 
gcj-dbtool or dlopen to load libgcj-tools.so.

(In fact, if it were not for the need to support the -J option, we 
wouldn't need any wrapper code at all, just a "gcj --main=... -o 
gwhatever -lgcj-tools")

There is certainly an argument that it would be nice to share the 
wrapper code with classpath, but in this case I'm not sure the extra 
complexity is worth it.

Bryce