Re: java library installation issues

[Tom Tromey <tromey@redhat.com>]

>>>>> "Per" == Per Bothner <per@bothner.com> writes:

Per> So to summarize:  The builtin search path should be (in this order):
Per> (1) each .jar file in /usr/share/java/$implementation
Per> (2) each .jar file in /usr/share/java
Per> (3) the /usr/share/java directory itself

I think we'll need a way to disable the built-in search path except
for libgcj.jar.

Per> Where should .so be installed?  The obvious location is /usr/lib.
Per> However, I'm wondering whether it might be better to separate out
Per> Java libraries in a separate directory for two reasons:
Per> (1) reduce clutter in /usr/lib

I don't think this is a real issue for Linux systems.  Packaging makes
clutter irrelevant.

Per> (2) reduce risk of library name clashes.

This might be an issue.

I personally prefer to keep using $libdir, since (1) that is the GNU
standard, and (2) it doesn't require any Linux-specific configuration
in the libgcj configure script.  I think we really do want to avoid #2.

Per> So I would suggest /usr/lib/gcj for .so files.  In that case the
Per> gcj command should add /usr/lib/gcj to the list of directories to
Per> search at run-time, with an ld -rpath command.

I think adding a -rpath is not a good idea.  If libraries end up
somewhere other than /usr/lib then the packager should put the new
directory into ld.so.conf.

Per> The final piece of magic I suggest: When the compiler compiles a
Per> Java class A and emits a reference to a class B (the class
Per> itself, a static method, or a static field of B), and B was found
Per> in L.jar in the builtin search path, then the compiler should
Per> check if there is a file /usr/lib/gcj/L.so.  If so, it should
Per> emit whatever magic is needed s that the linker searches L.so (at
Per> both ld and run-time-linke times).

The `L.so' in this case should probably follow the naming scheme we
adopted for the `.so' files that Class.forName will automatically try
to load.  That will make it so that the linker and Class.forName will
agree -- it won't matter to the end program whether a class is loaded
at runtime or at link time.

Tom