I used g++ instead of gcc now and it seems the error is fixed.
thanks for your help. l learned a lot about library files now.
Cheers,
Kason
Joi Ellis wrote:
> 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]
