Question: Inclusion of shared libraries during linking of shared libraries

Question: Inclusion of shared libraries during linking of shared libraries

Post by Pieter Winte » Wed, 04 Oct 2000 14:50:51



Hi,

I am compiling a dynamic loadable library (*.so) under Unix (I'm working
under Solaris, but I guess my question applies to other Unix versions also).
This library requires other .so libraries to function. Now there are 2 ways
I can deal with this:

1.    Include the header files of the included library during compilation.
Do _not_ include the included library during linking, or
2.    Include the header files of the included library during compilation,
_and_ include the included library during linking.

Both of these work. When doing ldd on the 1st and the 2nd approach, I can
see that in the 2nd case the included libraries are required.

Can anyone tell me the pros and cons of either method? What is the preferred
way of doing this?

--
Pieter Winter
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-IAQ: http://www.plethora.net/~seebs/faqs/c-iaq.html

 
 
 

Question: Inclusion of shared libraries during linking of shared libraries

Post by Chuck Dillo » Wed, 04 Oct 2000 04:00:00



> Hi,

> I am compiling a dynamic loadable library (*.so) under Unix (I'm working
> under Solaris, but I guess my question applies to other Unix versions also).
> This library requires other .so libraries to function. Now there are 2 ways
> I can deal with this:

> 1.    Include the header files of the included library during compilation.
> Do _not_ include the included library during linking, or
> 2.    Include the header files of the included library during compilation,
> _and_ include the included library during linking.

> Both of these work. When doing ldd on the 1st and the 2nd approach, I can
> see that in the 2nd case the included libraries are required.

In both cases the same libraries are required.  The difference is whether ld
can determine which libraries are required from the shared object.

If you use the first case all libraries must be specified explicitly
when you link a program to your library.  So the user of your library must
figure out which system libraries your shared library relies on.

In the second case your shared library contains enough information so that
the linker (ld) can resolve it's dependencies.  So if I were to use your
library it would be sufficient for me to just link to your shared library.
IOW, I don't care what other libraries it depends on (assuming they are found
by the linker).

Quote:

> Can anyone tell me the pros and cons of either method? What is the preferred
> way of doing this?

The second.

If you use ldd in /usr/lib you will see the many dependencies that exist.
I for one like not having to discover those dependencies each time I use
a system library.

Another argument is that a feature of shared objects is that they can provide
a 'plug in' capability.  You can change a shared library and extend the
capability of a program without relinking.  If I have a program that was no
linked to the libraries needed to use sockets but later wanted to replace
a shared object with one that uses sockets I can do that as long as the
shared object is linked against the required libraries.  The runtime linker
determines that the socket related libraries are needed at runtime by
examining the shared libraries recursively.

-- ced

--
Chuck Dillon
Senior Software Engineer
Genetics Computer Group, a subsidiary of Pharmacopeia, Inc.

 
 
 

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

I need to come up with a shared library whose name and function names are NOT
known at compile/link time - only known at runtime. This requires the
application program to be able to dynamically load a shared library at runtime
whose name is in a variable and request a function whose name is also in
a variable.

It would work like this: At run the application program would make a system
call to dynamically load a library by the name of the string it passed. Once
loaded, the application would, using a "handle" to the library, request a
reference to a function in the library passing the name of the function. In
servicing the request the library would lookup the function name in its table
and return a pointer to the function. The application would call the function
using the pointer.

If you're familiar with Windows (I'm not that familiar with) it would be
equivalent to the "LoadLibrary" and "GetProcAddress" functions in Windows.

I've read through a number of FAQs and group posting and so far haven't come
across anything of this nature.

ANY HELP YOU CAN PROVIDE WOULD BE WELCOME!!!

TIA, Mike

--

5910 N Central Exprwy, Suite 800   phone: (214)891-6638
Dallas, TX 75206-5140              fax:   (214)987-8187

2. ENTRY macro (coda maintainers please listen)

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

4. CPIO buffer size choice?

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

6. Linux memory 8meg to 12meg question?

7. Shared library loading shared library.

8. glibc errata for RedHat 7.0

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

10. link static libraries into a shared library

11. link shared libraries and use LD_LIBRARY_PATH question.

12. questions on linking with shared libraries

13. Shared libraries sharing from main app?