This is the mail archive of the
mailing list for the Java project.
Re: how to reference a lib*.so instead of using -I blat.jar
Andrew Haley wrote:
> Quick question ....
> I have a jar, A, that is dependent on another jar, B.
> Let's say I use gcj to compile B.jar down to a libB.so file.
> Now, when I go to compile A down to libA.so, I'm currently
> setting up the gcj command like:
> gcj -I B.jar -c -o libA.so A.jar
> What should I be doing instead to pick up the B.jar classes
> from libB.so instead of from "-I B.jar"
Fomr "man ld" :
Add archive file archive to the list of files to link. This option
may be used any number of times. ld will search its path-list for
occurrences of "libarchive.a" for every archive specified.
On systems which support shared libraries, ld may also search for
libraries with extensions other than ".a". Specifically, on ELF and
SunOS systems, ld will search a directory for a library with an exten-
sion of ".so" before searching for one with an extension of ".a". By
convention, a ".so" extension indicates a shared library.
Not certain I asked the question right. Or perhaps I'm just invoking
wrong. In the following gcj command, no matter where I put
I still get missing classes errors. But if I instead include
which that libjsapi.so file was compiled from in the -I list, everything
is okay. My assumption is I should be able to not use -I and
instead pick up the -ljsapi somehow to inform gcj re how the
missing classes would look.
gcj $GCJ_FLAGS \
-I /opt/IBMJava2-142/jre/lib/graphics.jar \
-I ~/tts/freetts/lib/cmulex.jar \
-I ~/tts/freetts/lib/en_us.jar \
-c -o $TLIB/libfreetts.so \
-L$TLIB -ljsapi \
$TLIB/libjsapi.so exists. It was created by:
gcj $GCJ_FLAGS \
-c -o $TLIB/libjsapi.so \
I'm guessing this is such a simple thing that it's painfully
obvious to everyone else on the list. I apologize for this