I was wondering if someone could tell me how(if possible) this can be done.

  I am writing a shared library that an executable will load int at runtime.  The
shared library I wrote needs to use symbols and functions from another shared
library that was not part of the link line of the executable.  Is there a way for
a shared library to tell the executable that it needs other library loaded that the
executable didn't link in.

  Is there a command line option to ld when creating a shareed library to use
other libraries?

  Is there a link option for the executable to shared libraries to link in other
shared libraries not in the link line?

Illustration
----------
Executable:
CC -o myProgram *.o -lmyLib

My shared library:
ld -G -b -o libmyLib.so
  ** myLib needs another library libotherLib.so

PS.  I am using SUNWspro CC4.1 compiler.

Thanks for any help,
Greg.

--
Gregory Gee
Nortel ISPN
Phone: (613)763-6175 ESN 393
email: g...@nortel.com
email: g...@playground.net

  I am writing a shared library that an executable will load int at runtime.  The
shared library I wrote needs to use symbols and functions from another shared
library that was not part of the link line of the executable.  Is there a way for
a shared library to tell the executable that it needs other library loaded that the
executable didn't link in.

  Is there a command line option to ld when creating a shareed library to use
other libraries?

  Is there a link option for the executable to shared libraries to link in other
shared libraries not in the link line?

Illustration
----------
Executable:
CC -o myProgram obj1.o obj2.o -lmyLib

My shared library:
ld -G -b -o libmyLib.so file1.o file2.o
  ** myLib needs another library libotherLib.so

PS.  I am using SUNWspro CC4.1 compiler.

Thanks for any help,
Greg.

--
Gregory Gee
Nortel ISPN
Phone: (613)763-6175 ESN 393
email: g...@nortel.com
email: g...@playground.net

/JAH

"Gee, Gregory (EXCHANGE:CAR:5D22)" <g...@americasm01.nt.com> writes:

Yes, same as for programs

You shouldn't link with ld in the first place.  You should link w/ CC.

Here's how:

        CC -G -o libmyLib.so *objects* -lotherlib

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Casper H.S. Dik - Network Security Engineer wrote:

Just curious - what reason do you have for this statement?  I've found linking with
ld to be very useful in certain situations, particularly when mixing, say, COBOL
objects with C objects...the only drawback I've noticed is the difficulty figuring
out which options and switches to use...but that's usually just a matter of studying
the man pages...

 There is no reason. cc usually calls ld under the covers. If you know what options it
is to be called with (on AIX it is in /etc/xlc.cfg), you can call ld yourself. If you
want to do things like linking MF Cobol programs with C++ code, sometimes that could be
the only alternative if you want to have full control over how crt0.o and the
equivalents are to be used.

/JAH

Well, teh reason for not using ld directly is precisely that it's difficult
and error prone.

You might be inclined to call ld like this:

        ld -G -o hello.so hello.o

rather than the correct form:

/usr/ccs/bin/ld -dy -G -z text -R/opt/SUNWspro/lib -o hello.so \
    /opt/SUNWspro/SC4.2/lib/crti.o hello.o -Y P,/opt/SUNWspro/lib:\
    /opt/SUNWspro/SC4.2/lib:/opt/SUNWspro/lib/rw7:/opt/SUNWspro/SC4.2/lib/rw7:\
    /usr/ccs/lib:/usr/lib /opt/SUNWspro/SC4.2/lib/crtn.o

Also note that the order of the object files is important.

(crti.o must be linked before all other objects, crtn.o must be linked
after all others)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Casper H.S. Dik - Network Security Engineer wrote:

I stand partly corrected. Simplicity and  portability, if the linking conditions are
uncomplicated, are valid reasons. Especially since one usually can give specific ld options
on the cc command line should the need arise. I guess it is like most things - one has to
take a pick depending of what is to be accomplished.

/JAH

  Thanks for the suggestions so far.  I noticed that that the symbol that could not
be resolved was a global variable in the shared library.  Currently I am compiling
with "ld -G -o libMDR.so file1.o file2.o".  Is there an ld options or should I use
CC that will help resolve global variables as well as function calls.

ld.so.1: ./fmdrAdapter: fatal: relocation error: file ./libMDR.so: symbol snmpErrno: referenced symbol not found
Killed

  The snmpErrno is a global variable in the shared library that my shared library
is using.

Greg.

--
Gregory Gee
Nortel ISPN
Phone: (613)763-6175 ESN 393
email: g...@nortel.com
email: g...@playground.net