From: Daniel Russell < russed@rpi.edu>
Subject: What is dynamic linking
Date: Tue, 12 Jan 1993 20:19:34 +0200
I have been trying to follow the discussions here regarding
dynamic linking. I hate to broadcast by ignorance, but I don't
understand what Eric's code (or PIC, or...) accomplishes. I read and
(mostly) understood Eric's piece in the latest Linux News, but still
have some questions.
Is it simply (!) a new, easier way to create a library?
Are the current jumptable libs `dynamic', since they can be changed just by
recompiling and updating the link?
What are some benefits of (say) Eric's method vs. the current method.
No need to reply to everyone if the answers are commonly known.
TIA,
dan
=====
Dan Russell russed@rpi.edu Linux Forever!
If you have to say "obviously," maybe it's not so obvious
From: eric@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: What is dynamic linking
Date: Wed, 13 Jan 1993 02:29:14 +0200
> I have been trying to follow the discussions here regarding
>dynamic linking. I hate to broadcast by ignorance, but I don't
>understand what Eric's code (or PIC, or...) accomplishes. I read and
>(mostly) understood Eric's piece in the latest Linux News, but still
>have some questions.
There are a couple of issues here. The easiest way to make things
clear is to tell you what is wrong with not doing dynamic linking.
Currently when we build a library, we are essentially linking a program
and the linker resolves all of the references internally. An example of this
would be malloc(), as this is called by strdup(). Now, let us say that
we wanted to define our own malloc function, which a number of packages do,
and we use strdup to duplicate a string. The pointer we get back from strdup
was obtained by calling the malloc compiled into libc, but everywhere we
explicitly call malloc in our own program we use our own version. Now let us
say we need to call free(). If we call free explicitly, we end up calling our
own free and not the version compiled into the library. If the memory was
malloced by the internal malloc from libc then the internal pointers are
probably all wrong and our free will just end up corrupting memory.
This is just one example of course, obz can tell you about a problem case in
the X libraries that was a pain in the butt to work around, and I think that
there were similar problems compiling emacs and so forth.
Now, let us say that we linked the program statically. In this case
we have defined our own malloc function, and the library version is not needed.
The linker will connect the call in strdup to the malloc that we are supplying
and everything should be OK.
The idea behind dynamic linking is that we want a shared library to use
the same type of linkage that a static library does. Therefore, if we defined
our own version of a function that is already in a library, that it will appear
as if the library function is not even there, and the library will call our
version instead of the version that is built into libc. Thus we should be able
to link a program to a sharable library without fear that something will go
wrong.
PIC is a side issue almost. Some implementations of sharable libraries
will load the code for the sharable library at any convenient address in
memory, and as a result the code had better be Position-Independent-Code (PIC).
The only reason that I was fooling with PIC was that we need to make sure that
it is easy to switch the sharable library to use a version of a global variable
that exists in a users program instead of the library version. Typically the
way this is done, we reference each global variable through a pointer, and
if we are going to have a global variable in the users program instead we
simply need to modify this pointer. It turns out that PIC provides something
like this, and this is the reason that I was investigating PIC. In my
implementation of dynamic linking, the libraries are at fixed addresses
so there is no requirement that the code be position independent.
>Is it simply (!) a new, easier way to create a library?
>Are the current jumptable libs `dynamic', since they can be changed just by
>recompiling and updating the link?
>What are some benefits of (say) Eric's method vs. the current method.
The current jumptable libs could be dynamic in part because we could
in theory change the jump instruction to point to the users program. The
problem is that internally, the library calls itself without going through the
jump table and thus we could not implement dynamic linking in a jumptable
library simply by modifying the jump instruction. Also, there is no way to
redirect a global variable to another address in the jump-table versions of the
library.
The benefits are mainly that programs will tend to be more reliable in
the long run. It is usually the more complicated ones that redefine library
functions, and it gets to be really hard to debug a program if you cannot keep
track of which version of a function is really being called.
-Eric