This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: patches to re-direct _Jv_RegisterClass
- To: "Anthony Green" <green at redhat dot com>
- Subject: Re: patches to re-direct _Jv_RegisterClass
- From: Per Bothner <per at bothner dot com>
- Date: 06 Jul 2001 23:11:51 -0700
- Cc: <java-patches at gcc dot gnu dot org>
- References: <m2u218owwn.fsf@kelso.bothner.com><871yocarlq.fsf@creche.redhat.com> <m2n16y4g3v.fsf@kelso.bothner.com><87lmmh3g6a.fsf@creche.redhat.com> <m2ofrdbqu0.fsf@kelso.bothner.com><87r8vtsvl5.fsf@creche.redhat.com><000001c1069a$9ff5c960$5be6b4cd@cygnus.com>
"Anthony Green" <green@redhat.com> writes:
> Also, our current scheme uses library names foo-bar-class.so. This is
> inconvenient if you need to link against them (-lfoo-bar-class doesn't
> work). Should we change these to libfoo-bar-class.so? Or
> libgcj-foo-bar-class.so?
I think libfoo-bar-class.so would be more standard. I would like a
convention that for each "library" XYZ we install both a XYZ-VERSION.jar
(in $prefix/share/gcj or $prefix/share/java) and a XYZ-VERSION.so
(in $prefix/lib).
I'm not sure about the convention mapping package prefixes to
library names in VMClassLoader::findClass. Is it actually used?
A model closer to Sun's extensions mechanism would be to just
search $prefix/share/gcj/*.jar, if it hasn't already been registered.
--
--Per Bothner
per@bothner.com http://www.bothner.com/per/