Building an app with gcj and readline

[Mark Wielaard]

Hi,

On Sat, 2004-10-30 at 15:14, David N. Welton wrote:
> Mark W. asked me to write and "complain" here a bit about the process
> of building my app.

Thanks. It is good to see what isn't as obvious (or clearly documented)
as we would like.

> Basically, my app builds reasonably well with gcj, and it's not that
> hard to figure out.  It's fairly similar to how I use gcc.
> 
> However, the problems start when I try and link the whole thing with
> libreadline-java on my Debian (testing) system.

It took us a while to realize that libreadline-java uses jni to link
against the libJavaReadline.so library that links against the
libreadline C library.

>   I eventually figured
> things out with Mark's patient help on irc, and ended up with the
> following:
> 
> librl.so: /usr/share/java/libreadline-java.jar
> 	gcj-3.4 -fjni -fPIC -shared -Wl,-soname,librl.so -o librl.so /usr/share/java/libreadline-java.jar

It would be nice if the Debian package already did this (and then
compiled from source of course). When named lib-org-gnu-readline.so and
installed in a standard library path the native version will even be
used by interpreted classes with gij.
(See http://gcc.gnu.org/onlinedocs/gcj/Extensions.html)

> rlhecl: classes librl.so
> 	gcj-3.4 -g -o rlhecl --main=com.dedasys.hecl.RLHecl com/dedasys/hecl/*.class  -L. -lrl -I/usr/share/java/libreadline-java.jar
> 
> and to get it to run correctly, I had to set the LD_LIBRARY_PATH to
> include not only the build directory (for "librl.so"), but
> /usr/lib/jni
> 
> Some things that wouldn't have seemed natural to me to try:
> 
> 1) -fjni - wouldn't have thunk of it myself.

Normally native code is written in CNI and gets linked at
compile/runtime. Legacy code often uses JNI code which gets linked at
runtime (through System.loadLibrary()). In that case you will get a link
error if you forget the -fjni flag.

> 2) -I/usr/share/java/libreadline-java.jar - didn't I already compile
>     that into the shared lib?  Seems odd.

Since java source files don't have separate header and implementation
you can use the .class or .jar files as precompiled header files. You
link against the shared library, but your sources get compiled against
the headers (classes) just like you link against a .so written in C, but
compile against the .h files.

> 3) having to set LD_LIBRARY_PATH is a bit of a pain.  It would be nice
>    for deployment if that weren't necessary.
> 
> Mark mentions that -Djava.library.path=/usr/lib/jni ought to make the
> library path part go away, but I'll let him deal with that.

Didn't found out yet why this doesn't work. It is [Bug libgcj/18234]
"System property java.library.path doesn't get used by
System.loadLibrary()" in bugzilla now.

Again, since Debian has as policy to install JNI libraries in
/usr/lib/jni it would be nice if they made sure their libgcj
(System.loadLibrary()) looks their by default. Maybe when we fix the
above bug we should add a --with-extra-jni-lib=/some/path configure
option for distributions.

> Anyway... I'm really not complaining - Mark asked me to write down
> some notes on this stuff, so here they are.  I'm really quite happy to
> have a free java system to use to hack on my project!

Thanks. It was nice to see some real world use.
I hope your experiences help us make some better documentation and/or
recommendations for packagers of libraries written in the java
programming language and deployed with gcj.

Cheers,

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://gcc.gnu.org/pipermail/java/attachments/20041030/0dec45e2/attachment.sig>