On Tue, 31 Oct 2000, kason wong wrote:
> Hi,
>
> I guess I know what's the really problem is.
>
> I think I should make my problem more clear. I used to use libutil.a libpthread.a
>libcops.a to make ReqMsg.cxx executable. now I want to use COPS.cxx and
> .h files (JNI layers) to link a java program to call ReqMsg. so I modified a little
>of you Makefile to do it.
>
> and after that in my java code, should i just load COPS
> or I need to load cops, util, pthread too?
I'm not familiar with COPS and cops.
Ignoring the whole threads mismatch issue, you load the single
library, libutil.so. The gcc/link step creates that lib so that it
is entirely self-contained. The linker pulls your .o files,
routines from all of the libraries presented on the g++ command, plus the
standard default libs, and writes everything into the target libutil.so
file that isn't part of the standard load path. It doesn't actually
write copies of the system library code, it writes pointers to it so that
the dynamic loader knows where to look for them. This makes your .so
file smaller than a static-linked module. (It also seems to be the
only library format JVMs know how to load.)
So, you only need to loadLibrary("util"). You don't need to load
anything it depends upon because that's already been taken care of
by the linker.
If 'ldd -r' finds missing symbols, fix the g++/link command. You can't
get around it by using java's loadLibrary(). It never worked when I
tried it, either.
> if i need to load all the libraries, the problem is I can't not ldd libutil and
>libpthread.so alone. it gives me alot of undefined symbol errors ..
Every single library your app uses must be present in either the LINKLIBS
variable or in the JAPILIBS/APILIBS/APISOLIBS variables. The ONLY library
you need to run 'ldd -r' against is your own. It's pointless running it
against system libraries, and you don't loadLibrary() system libraries.
> from the lib size I can see libCOPS.so doesn't include the objects in libcops,
>libpthread or libutil.so.
> -rwxr-xr-x 1 kwong kwong 360429 Oct 31 14:55 libCOPS.so*
> -rw-r--r-- 1 kwong kwong 6834356 Oct 29 13:44 libcops.a
> -rwxr-xr-x 1 kwong kwong 2352811 Oct 30 15:56 libcops.so*
> -rw-r--r-- 1 kwong kwong 668698 Oct 30 12:07 libpthread.a
> -rwxr-xr-x 1 kwong kwong 243595 Oct 30 18:23 libpthread.so*
> -rw-r--r-- 1 kwong kwong 6469118 Oct 29 18:27 libutil.a
> -rwxr-xr-x 1 kwong kwong 3061632 Oct 31 14:56 libutil.so*
Don't make too many assumptions based on size. The link may pull only
a handful of routines from a large library to build your own library
or object file. If you really want to see what's going on, make sure
your Makefile contains:
LDOPT=-Xlinker -t -Xlinker -Map -Xlinker /tmp/linkmap -Xlinker -cref
and then peer at /tmp/linkmap and see what it actually did. That map
is a contents and symbol list of your libutil.so file.
--
Joi Ellis Software Engineer
Aravox Technologies [EMAIL PROTECTED], [EMAIL PROTECTED]
No matter what we think of Linux versus FreeBSD, etc., the one thing I
really like about Linux is that it has Microsoft worried. Anything
that kicks a monopoly in the pants has got to be good for something.
- Chris Johnson
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
