Re: RFA: enable gappletviewer, gjarsigner and gkeytool tools

[Thomas Fitzsimmons <fitzsim at redhat dot com>]

Hi,

Bryce McKinlay wrote:
> 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.

The relocatable tree problem still exists, everywhere in Makefile.am where we 
use -rpath.  Solving that in a general way would also solve the libjvm.so 
problem.  See:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28175

> b) The tools will work out-of-the-box on platforms that may not support 
> JNI / JNI invocation for whatever reason (win32?)

Making the tools work "out-of-the-box" no matter what the approach will take 
testing and bug fixing.  I argue that we should fix the problems with JNI / JNI 
invocation on those platforms.  That is one of the reasons I like my approach, 
is that it exercises JNI and the JNI invocation implementation.

How well-tested is the BC ABI on the platforms that may not support JNI 
invocation?  Do we test linking directly to a BC library on *any* platform?

> c) Native compiled code will be used automatically, no need for 
> gcj-dbtool or dlopen to load libgcj-tools.so.

We'll still need gcj-dbtool so that libgcj-tools.so is located by Java apps that 
 use libgcj-tools.jar, like Ant.

> (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")

Yes, if I'm going to rewrite and retest this patch using CNI, I'll take this 
simplistic approach.

> 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.

I view an extra CNI wrapper as extra complexity from the maintenance standpoint. 
 I'd like to see all free GNU Classpath-based runtimes use the same tools strategy.

Tom