Shared Library Question

[David T. Ashley]

I've occasionally had trouble compiling and linking programs that use shared
libraries. That never made a lot of sense to me, because I thought the
operating system went hunting for the symbols and libraries at runtime (and
not before).

Questions:

a)How do the development tools know that a given symbol (a function entry
point, for example) is located in a shared library and won't be linked in
statically?

b)When a shared library is used and you compile and link a program, what
happens during the "link" step? (Does the OS be sure the symbols exist, be
sure it knows the location of the shared library, what?)

c)Is the location of the shared library embedded in the ELF file somehow?

d)As an example, when one compiles applications to use GMP, one includes
"gmp.h". I need to look at this header file ... but is the location of the
library on the target system in this file?

Thanks.

 

[David T. Ashley]

I've occasionally had trouble compiling and linking programs that use
shared libraries. That never made a lot of sense to me, because I thought
the operating system went hunting for the symbols and libraries at runtime
(and not before).

Questions:

a)How do the development tools know that a given symbol (a function entry
point, for example) is located in a shared library and won't be linked in
statically?

b)When a shared library is used and you compile and link a program, what
happens during the "link" step? (Does the OS be sure the symbols exist,
be sure it knows the location of the shared library, what?)

c)Is the location of the shared library embedded in the ELF file somehow?

d)As an example, when one compiles applications to use GMP, one includes
"gmp.h". I need to look at this header file ... but is the location of
the library on the target system in this file?

OK, I found this link:

http://users.actcom.co.il/~choo/lupg/tutorials/libraries/unix-c-libraries.html#using_shared_library

which answered most of my questions.

I guess my only question left is then the following:

e)If the shared library isn't in a standard location, is setting the
environment variable LD_LIBRARY_PATH the only way to tell the loader where
to find it?

f)And question (c) is also still relevant.

Thanks.

 

[Jack Klein]

I've occasionally had trouble compiling and linking programs that use shared
libraries. That never made a lot of sense to me, because I thought the
operating system went hunting for the symbols and libraries at runtime (and
not before).

Questions:

a)How do the development tools know that a given symbol (a function entry
point, for example) is located in a shared library and won't be linked in
statically?

b)When a shared library is used and you compile and link a program, what
happens during the "link" step? (Does the OS be sure the symbols exist, be
sure it knows the location of the shared library, what?)

c)Is the location of the shared library embedded in the ELF file somehow?

d)As an example, when one compiles applications to use GMP, one includes
"gmp.h". I need to look at this header file ... but is the location of the
library on the target system in this file?

Thanks.

Kindly do not cross post questions about tools, linkers, shared
libraries, EOF files, and the like to comp.lang.c, where they are 100%
off-topic.

 

[Jack Klein]

OK, I found this link:

http://users.actcom.co.il/~choo/lupg/tutorials/libraries/unix-c-libraries.html#using_shared_library

which answered most of my questions.

I guess my only question left is then the following:

e)If the shared library isn't in a standard location, is setting the
environment variable LD_LIBRARY_PATH the only way to tell the loader where
to find it?

f)And question (c) is also still relevant.

Thanks.

Kindly do not cross post questions about tools, linkers, shared
libraries, EOF files, and the like to comp.lang.c, where they are 100%
off-topic.

 

[Guest]

| I've occasionally had trouble compiling and linking programs that use shared
| libraries. That never made a lot of sense to me, because I thought the
| operating system went hunting for the symbols and libraries at runtime (and
| not before).

At compile time, the linking that happens determines which library the
various symbols are expected to be resolved from so it can know which
libraries the resultant file depends on. Would you want the runtime
linker to have to look everywhere for every symbol? What's going on is
doing as much as it can at compile time that is still compatible with
linking the executable to the libraries as fast as possible. The goal
is to be able to share the libraries, and to a lesser extent support an
upgrade of a library with no impact (as long as all the symbols are
still there). Having teh runtime linking do all the work normally done
by the compile time linker would make program starts a good bit slower.
And that's work that doesn't need to be done at runtime in 99.999% of
cases.


| Questions:
|
| a)How do the development tools know that a given symbol (a function entry
| point, for example) is located in a shared library and won't be linked in
| statically?

It looks at all the libraries in the designated search order. If it is
in one that is linked statically, it will know that and include the member
of the library in the resultant image. If it is in one that is linked
dynamically, then it will note that library is to be linked at runtime.


| b)When a shared library is used and you compile and link a program, what
| happens during the "link" step? (Does the OS be sure the symbols exist, be
| sure it knows the location of the shared library, what?)

It determines which libraries each symbol is found in (see above answer).
It determines which libraries need to be linked at runtime. If any dynamic
libraries are included, it also specifes the runtime linker as the image
interpreter.


| c)Is the location of the shared library embedded in the ELF file somehow?

It can be. Or it can be left to fine the library based on cached data
that tells which paths various libraries are found at on the given system.


| d)As an example, when one compiles applications to use GMP, one includes
| "gmp.h". I need to look at this header file ... but is the location of the
| library on the target system in this file?

No. The system has a set of default directories to look for libraries
and the linker command line lists a set of libraries to be examined.
Each library name will be looked for in each of the directories in the
specified order. The "-l" option identifies a library include and the
"-L" option identifies a directory to include. You can also just add
the full path of the library on the command line. If the .so file is
found, it prefers that over a .a file, unless you tell it to link all
statically. If only a .a file is found, that much is linked statically.
There are also options to control how the name/version selection is done
at runtime to make sure compatible libraries are linked to.

 

[David T. Ashley]

| I've occasionally had trouble compiling and linking programs that use
shared
| libraries. That never made a lot of sense to me, because I thought the
| operating system went hunting for the symbols and libraries at runtime
(and
| not before).

At compile time, the linking that happens determines which library the
various symbols are expected to be resolved from so it can know which
libraries the resultant file depends on.

<Much other useful information snipped for brevity.>

Phil,

Thanks for the very helpful reply. Your reply plus a couple other replies
on comp.unix.programmer have really pointed me in the right direction
technically and in terms of finding documentation for parts of the standard
toolset.

I do understand the complaint that was made on comp.lang.c about my post
being off-topic. I think this complaint is legitimate. However, my
personal style has always been to be helpful as a first priority and to
steer people in different directions as a second priority. Posts appear on
comp.lang.c that are off-topic (rational approximation, computer arithmetic,
etc.), and I don't find them ... disruptive.

In any case, I'm glad YOU were willing to help out. I have much reading to
do.

Thanks, Dave.