[Kde-bindings] providing native shared libraries of qtjava

[Adeodato Simó]

hi,

  [sorry for the crosspost, I'm not sure which list is the appropriate
  one. please follow-up to either of them, I'm subscribed.]

  as you may or may not know, I've taken over the maintenance of
  kdebindings in Debian after Dominique Devriese left.

  at the request of an user, I'm adding some documentation bits
  (attached) as of how to produce native executables of programs that
  make use of qtjava. that procedure includes compiling the qtjava.jar
  set of classes into native code, either including it in the executable
  or making it into a sepparate shared library.

  I've been told by an upstream gcj developer that compiling into native
  from bytecode (*.class) and not from source (*.java) is sub-optimal,
  and that in fact would make sense to ship a shared native qtjava
  library compiled from sources.

                                 * * *

  so, my question to the list are specifically these:

    (a) if there is a reason why I shouldn't build that shared library
        and ship it in the Debian packages

    (b) if there is a reason as of why the upstream build system does
        not build it by default already and, in case it hasn't been
        proposed before, if it would be possible to do so

    (c) what would be, if decided to build and ship it, the name of the
        library: libqtgcj?, libqtjava-shared?, some other?...

                                 * * *

  and that was all, thanks in advance.

-- 
Adeodato Simó
    EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
    Listening to: David Bowie - Slow burn
 
I try to keep an open mind, but not so open that my brains fall out.
-------------- next part --------------
Generating native executables
-----------------------------

It is also possible to produce native executables with the following gcj
invocation:

	export CLASSPATH="/usr/share/java/qtjava.jar:/usr/share/java:."
	gcj -fjni Somefile.java /usr/share/java/qtjava.jar --main=Somefile
	LD_LIBRARY_PATH=/usr/lib/jni ./a.out

As this will compile the full qtjava.jar into native code, the resulting
executable will be rather large. If you plan on having several of these
executables, it may be worth creating a shared qtjava library, like
this:

	gcj -fjni -shared /usr/share/java/qtjava.jar -o libqtjava-shared.so

And then, after you put libqtjava-shared.so in /usr/lib or similar, you
can go like:

	gcj -fjni Somefile.java --main=Somefile -lqtjava-shared
	LD_LIBRARY_PATH=/usr/lib/jni ./a.out

In the future, I'll investigate the possibility of shipping the
qtjava-shared library in the Debian packages.

Also, in order to avoid the necessity of setting the LD_LIBRARY_PATH
environment variable, the option -Djava.library.path=/usr/lib/jni can be
passed to the gcj invocation. There is, however, a bug [1] in gcj that
prevents this from working, and it's only fixed in gcj-4.0.

    [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18234