egonw <[EMAIL PROTECTED]> writes:
> Ok, in addition to the current Debian policy, a third, preferred
> option, being the gcj compiled library.
Yes. The interpreter (VM) that is part of the gcj run-time library
allows you to include a .so in the classpath, and it is searched for
needed classes just like classes in a .jar file. Of course all
the classes in a .so would get loaded at once, but they would
not necessarily be entered in the global table of named classes
(or initialized) until needed by Java language rules.
> Indeed. But the principle holds that in Debian, with dependencies, that
> a certain executable exactly knows where to find a certain library.
> The build and run dependencies basically refer to an other package of
> which the file structure is determined. Once a maintainer changes this
> dir structure and thus file locations it possibly breaks many packages...
> This is why policies are so important.
No disagreemnt there.
> My point is that in /usr/share/java/gcj it seems to refer to libraries
> used for gcj, instead of libraries compiled with gcj.
It would be both.
> Now comes the reason why i failed to respond correctly to the issue;
> How does a Java program (in Java byte code), use a gcj compiled
> library?
First, a gcj (native-)compiled library can only be used by the gcj
run-time. It cannot be used by other Java implementations. Also,
note that the gcj compiler at compile-time would use the .jar versions
to read the "symbols" of other libraries; the .so versions are
only used at link and run-time.
> Do you mean that in order to use gcj compiled libraries the program
> itself has to be gcj compiled as well?
Yes and no. A program can be bytecode-interpreted by the libgcj
run-time, and load in other libraries that are gcj-native-compiled.
After all, the standard classes are all native-compiled.
> Given Java source code that compiles with gcj to architecture-specific
> code, you would make it (Debian) policy to compile with gcj in order
> to use the gcj compiled libraries?
It would not be required - it would just be suggested, for improved
performance.
> Or maybe, to have two conflicting packages program and program-gcj?
I've concentrated on where things get installed, not so much on how
things get split into package, but here are soem notes on the latter.
For libraries it might be reasonable to have two packages:
(1) 'library' installs a .jar files (and documentation).
(2) 'library-gcj' depends on 'library' and 'gcj-runtime', and
installs a .so file.
The main downside of this approach is lots of little packages,
so it is mainly an issue of how distributions deal with (hide) this.
For example, it is possible that 'library-gcj' could be hidden from
from the default package management view, but automatically installed
if both 'library' and 'gcj-runtime' are installed.
Absent something like this, it may be simpler to just have a single
package. If installing 'library' also installs program.so.
For programs it is harder, because a native-compiled executable
won't run without the gcj runtime libraries. One option is the
shell script route: the script looks for a native-compiled
executable and if it doesn't find it load a jvm. I don't think
resolving this needs to be an issue for a generic GNU/Linux
FHS, but it is an issue for individual distributions. I think
Red Hat should just require gcj-runtime for any Java package
that can be compiled to native, because Red Hat should support gcj,
and Red Hat has not traditionally dealt with thousands of packages.
For Debian the choice might be different.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
