From: eric@tantalus.nrl.navy.mil (Eric Youngdale) Subject: Re: xterm problems with Xfree86 1.2 on Linux Date: Wed, 17 Feb 1993 19:48:10 GMT
In article <C2LK8z.Hu1@austin.ibm.com> jstump@auntbea.austin.ibm.com (John E. Stump) writes:
>In article <1993Feb16.235005.12252@serval.net.wsu.edu> hlu@eecs.wsu.edu (H.J. Lu) writes:
>>1.2 supports dynamic linking library.
>
>Could someone briefly explain what dynamic linking libraries under Linux
>means? I know what they are in the Windows and OS/2 world, but somehow
>think they are not the same in Linux.
I guess I should answer that question since I wrote it :-). Without
dynamic linking, the internal linkages between different functions are set when
the library is linked. Let us look at a simple example. The strdup function
essentially makes a duplicate copy of a string, and it needs to call malloc to
obtain memory to store the duplicate string. With the old non-DLL libraries,
it will always call the malloc that is in libc, and there is no way of changing
this. Now, if the user defines their own malloc/free functions the user
version would be called some times, and the libc version would be called at
other times, and you might call your version of free with memory that was
malloced by the libc malloc, and havoc ensues. This is an actual example of
why gdb would not work when compiled out of the box and linked to a non-DLL
library.
If you link the program staticly and you have your own malloc defined,
then strdup in libc will call the user malloc function, not the one in libc.
In this case, everything would work more or less the way you would expect it
to.
With dynamic linking, we are essentially trying to make things
work the same way with the shared library that it does with static linking.
With the new system in linux, the linker notices when the user defines a
function and there is a function by the same name in the shared library. The
linker constructs tables that are read at run time by __load.c, these tables
tell the loader to modify the jump instruction in the jump table so that it
points back to the user defined function. In the case of malloc, the version
in libc would never be called under any circumstances, because the jump
table now points to the version in the user program.
This is a rather simplistic explanation of how it all works. Global
data also needs to be dealt with, and this is treated a little differently from
functions as described above, but the net result is the same - if the user
defines a variable errno, then libc will store the error codes in the memory
location for errno in the user program, not in the memory location in libc that
was originally set aside for errno.
-Eric
--