Shared library loading shared library.

Shared library loading shared library.

Post by EXCHANGE:CAR:5D » Wed, 23 Sep 1998 04:00:00



  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


 
 
 

Shared library loading shared library.

Post by EXCHANGE:CAR:5D » Wed, 23 Sep 1998 04:00:00


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 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



 
 
 

Shared library loading shared library.

Post by Johan Hellstro » Thu, 24 Sep 1998 04:00:00


A Shared library typically needs all its symbols resolved at link time.
This means, that the OS will try to resolve external symbols at the time the shared
library is loaded. In reality this means, that all shared objects needed by any of the
program or any previosly loaded shared object will become loaded in turn. OS business -
Your main executable does not need to be aware of this.

/JAH


>   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.

 
 
 

Shared library loading shared library.

Post by Casper H.S. Dik - Network Security Engine » Thu, 24 Sep 1998 04:00:00


[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


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

Yes, same as for programs

Quote:>Illustration
>----------
>Executable:
>CC -o myProgram *.o -lmyLib
>My shared library:
>ld -G -b -o libmyLib.so
>  ** myLib needs another library libotherLib.so

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.

 
 
 

Shared library loading shared library.

Post by J. Ben » Thu, 24 Sep 1998 04:00:00



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

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

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...
 
 
 

Shared library loading shared library.

Post by Johan Hellstro » Fri, 25 Sep 1998 04:00:00




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

> 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

 
 
 

Shared library loading shared library.

Post by Casper H.S. Dik - Network Security Engine » Fri, 25 Sep 1998 04:00:00


[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


> 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.

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.

 
 
 

Shared library loading shared library.

Post by Johan Hellstro » Fri, 25 Sep 1998 04:00:00



> [[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


> > 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.

> 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

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

 
 
 

Shared library loading shared library.

Post by EXCHANGE:CAR:5D » Fri, 25 Sep 1998 04:00:00


  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


 
 
 

1. Will strip(debug shared library) == nodebug shared library ?

compiling the C++ code without debug option to produce object
files(.o) and then producing the shared library with them. Say, the
size of this library is SIZE_SO_NoD.

compiling the C++ code with debug option to produce object files(.o)
and then producing the shared library with them. Then, do 'strip
library_name'. Say, the size of this library is SIZE_SO_D.

Will SIZE_SO_NoD & SIZE_SO_D be exactly/almost equal ? If yes/no, why?
Also, what exactly 'mcs -d library_name' do? Does it reduce symbols
from the shared library which was produced without debug option also?

2. Help installing LINUX on AlphaStation 200

3. Help with building shared libraries with dependencies on other shared libraries

4. Help ? Solaris Buffered I/O

5. Question: Inclusion of shared libraries during linking of shared libraries

6. strange problem with bash shell

7. Need a Shared Library Guru: beyond simple shared library question

8. libttf.so.2 is needed to instal XFree86-?????-3.3.3...

9. When is a shared library not a shared library?

10. error in loading shared libraries: libXmu.so.6: cannot open shared object

11. Shared variable between main() and loaded shared library - dlopen()

12. Shared libraries sharing from main app?

13. Compiling static libraries as shared libraries