Discuss the significance and requirements of Linking in Compilation.Differentiate between static and dynamic linking.
Compiler Programs:
The preprocessor->Front End(the syntactic and semantic checker)->(Back End)the code generator->the optimizer->the assembler->link-loader, and of course, a driver program to invoke all these pieces and pass the right options to each.An optimizer can be added after almost any of these phases.
Linker:
An object file isn't directly executable; it needs to be fed into a linker first. The linker identifies the
main routine as the initial entry point (place to start executing), binds symbolic references to memory
addresses, unites all the object files, and joins them with the libraries to produce an executable.
Dynamic Linking:
Allows a system to provide a big collection of libraries with many useful services, but the program will look for these at runtime rather than having the library binaries bound in as part of the executable
If a copy of the libraries is physically part of the executable, then we say the executable has been statically linked; if the executable merely contains filenames that enable the loader to find the program's library references at runtime, then we say it has been dynamically linked. The canonical names for the three phases of collecting modules together and preparing them for execution are link-editing, loading, and runtime linking. Statically linked modules are link edited and then loaded to run them. Dynamically linked modules are link-edited and then loaded and runtime-linked to run them. At execution, before main() is called, the runtime loader brings the shared data objects into the process address space. It doesn't resolve external function calls until the call is actually made, so there's no penalty to linking against a library that you may not call
hello.o--statically linked with libc.a[ 750 Kbyte] results in a.out [506 Kbyte]
dynamically linked with libc.so[620 KB] results in a.out[5 KB]--library functions are mapped into the process at runtime
Note:Even with static linking, the whole of libc. a is not brought into the executable, just the routines
needed.
Benefits of Dynamic Linknig:
1. A dynamically linked executable is smaller than its statically linked counterpart. It saves disk
and virtual memory, as libraries are only mapped in to the process when needed. Formerly,
the only way to avoid binding a library copy into each executable was to put the service in the
kernel instead of a library, contributing to the dreaded "kernel bloat."
2. All executables dynamically linked to a particular library share a single copy of the library at
runtime. The kernel ensures that libraries mapped into memory are shared by all processes
using them. This provides better I/O and swap space utilization and is sparing of physical
memory, improving overall system throughput. If the executables were statically linked, each
would wastefully contain its own complete duplicate copy of the library.
For example, if you have eight XView™ applications running, only one copy of the XView library
text segment has to be mapped into memory. The first process's mmap call will result in the kernel
mapping the shared object into memory. The next seven process mmaps will cause the kernel to share
the existing mapping in each process. Each of the eight processes will share one copy of the XView
library in memory. If the library were statically linked, there would be eight individual copies
consuming more physical memory and causing more paging.
3.Dynamic linking permits easy versioning of libraries. New libraries can be shipped; once installed on
the system, old programs automatically get the benefit of the new versions without needing to be
relinked.
Major advantage----------------
A major purpose of dynamic linking is to decouple programs from the particular library
versions they use. Instead, we have the convention that the system provides an interface to
programs, and that this interface is stable over time and successive OS releases.
Programs can call services promised by the interface, and not worry about how they are
provided or how the underlying implementation may change. Because this is an interface
between application programs and the services provided by library binary executables, we
call it an Application Binary Interface or ABI.
A single ABI is the purpose of unifying the UNIX world around AT&T's SVr4. The ABI
guarantees that the libraries exist on all compliant machines, and ensures the integrity of the
interface. There are four specific libraries for which dynamic linking is mandatory: libc (C
runtimes), libsys (other system runtimes), libX (X windowing), and libnsl (networking
services). Other libraries can be statically linked, but dynamic linking is strongly preferred.
In the past, application vendors had to relink their software with each new release of the OS
or a library. It caused a huge amount of extra work for all concerned. The ABI does away
with this, and guarantees that well-behaved applications will not be affected by well-
behaved upgrades in underlying system software
Finally dynamic linking allows users to select at runtime which library to execute against. It's possible to create library versions that are tuned for speed, or for memory efficiency, or that contain extra debugging information, and to allow the user to express a preference when execution takes place by substituting one library file for another.
Dynamic linking is "just-in-time" linking. It does mean that programs need to be able to find their
libraries at runtime. The linker accomplishes this by putting library filenames or pathnames into the
executable; and this in turn, means that libraries cannot be moved completely arbitrarily. If you linked
your program against library /usr/lib/libthread.so, you cannot move the library to a
different directory unless you specified it to the linker. Otherwise, the program will fail at runtime
when it calls a function in the library, with an error message like:
ld.so.1: main: fatal: libthread.so: can't open file: errno=2
This is also an issue when you are executing on a different machine than the one on which you
compiled. The execution machine must have all the libraries that you linked with, and must have them
in the directories where you told the linker they would be. For the standard system libraries, this isn't a
problem.
The main reason for using shared libraries is to get the benefit of the ABI—freeing your software from
the need to recompile with each new release of a library or OS. As a side benefit, there are also overall
system performance advantages.
Anyone can create a static or dynamic library. You simply compile some code without a main routine,
and process the resulting .o files with the correct utility—"ar" for static libraries, or "ld" for dynamic libraries.
NOTE:
1.A dynamically linked library is created by the link editor, ld. The conventional file extension for a
dynamic library is ".so" meaning "shared object"—every program linked against this library shares the
same one copy, in contrast to static linking, in which everyone is (wastefully) given their own copy of
the contents of the library. In its simplest form, a dynamic library can be created by using the -G
option to cc, like this:
2.Static libraries are known as archives and they are created and updated by the ar—for archive—
utility. The ar utility is misnamed; if truth in advertising applied to software, it would really be called
something like glue_files_together or even static_library_updater.
Convention dictates that static libraries have a ".a" extension on their filename
Reference: Expert C Programming
Compiler Programs:
The preprocessor->Front End(the syntactic and semantic checker)->(Back End)the code generator->the optimizer->the assembler->link-loader, and of course, a driver program to invoke all these pieces and pass the right options to each.An optimizer can be added after almost any of these phases.
Linker:
An object file isn't directly executable; it needs to be fed into a linker first. The linker identifies the
main routine as the initial entry point (place to start executing), binds symbolic references to memory
addresses, unites all the object files, and joins them with the libraries to produce an executable.
Dynamic Linking:
Allows a system to provide a big collection of libraries with many useful services, but the program will look for these at runtime rather than having the library binaries bound in as part of the executable
If a copy of the libraries is physically part of the executable, then we say the executable has been statically linked; if the executable merely contains filenames that enable the loader to find the program's library references at runtime, then we say it has been dynamically linked. The canonical names for the three phases of collecting modules together and preparing them for execution are link-editing, loading, and runtime linking. Statically linked modules are link edited and then loaded to run them. Dynamically linked modules are link-edited and then loaded and runtime-linked to run them. At execution, before main() is called, the runtime loader brings the shared data objects into the process address space. It doesn't resolve external function calls until the call is actually made, so there's no penalty to linking against a library that you may not call
hello.o--statically linked with libc.a[ 750 Kbyte] results in a.out [506 Kbyte]
dynamically linked with libc.so[620 KB] results in a.out[5 KB]--library functions are mapped into the process at runtime
Note:Even with static linking, the whole of libc. a is not brought into the executable, just the routines
needed.
Benefits of Dynamic Linknig:
1. A dynamically linked executable is smaller than its statically linked counterpart. It saves disk
and virtual memory, as libraries are only mapped in to the process when needed. Formerly,
the only way to avoid binding a library copy into each executable was to put the service in the
kernel instead of a library, contributing to the dreaded "kernel bloat."
2. All executables dynamically linked to a particular library share a single copy of the library at
runtime. The kernel ensures that libraries mapped into memory are shared by all processes
using them. This provides better I/O and swap space utilization and is sparing of physical
memory, improving overall system throughput. If the executables were statically linked, each
would wastefully contain its own complete duplicate copy of the library.
For example, if you have eight XView™ applications running, only one copy of the XView library
text segment has to be mapped into memory. The first process's mmap call will result in the kernel
mapping the shared object into memory. The next seven process mmaps will cause the kernel to share
the existing mapping in each process. Each of the eight processes will share one copy of the XView
library in memory. If the library were statically linked, there would be eight individual copies
consuming more physical memory and causing more paging.
3.Dynamic linking permits easy versioning of libraries. New libraries can be shipped; once installed on
the system, old programs automatically get the benefit of the new versions without needing to be
relinked.
Major advantage----------------
A major purpose of dynamic linking is to decouple programs from the particular library
versions they use. Instead, we have the convention that the system provides an interface to
programs, and that this interface is stable over time and successive OS releases.
Programs can call services promised by the interface, and not worry about how they are
provided or how the underlying implementation may change. Because this is an interface
between application programs and the services provided by library binary executables, we
call it an Application Binary Interface or ABI.
A single ABI is the purpose of unifying the UNIX world around AT&T's SVr4. The ABI
guarantees that the libraries exist on all compliant machines, and ensures the integrity of the
interface. There are four specific libraries for which dynamic linking is mandatory: libc (C
runtimes), libsys (other system runtimes), libX (X windowing), and libnsl (networking
services). Other libraries can be statically linked, but dynamic linking is strongly preferred.
In the past, application vendors had to relink their software with each new release of the OS
or a library. It caused a huge amount of extra work for all concerned. The ABI does away
with this, and guarantees that well-behaved applications will not be affected by well-
behaved upgrades in underlying system software
Finally dynamic linking allows users to select at runtime which library to execute against. It's possible to create library versions that are tuned for speed, or for memory efficiency, or that contain extra debugging information, and to allow the user to express a preference when execution takes place by substituting one library file for another.
Dynamic linking is "just-in-time" linking. It does mean that programs need to be able to find their
libraries at runtime. The linker accomplishes this by putting library filenames or pathnames into the
executable; and this in turn, means that libraries cannot be moved completely arbitrarily. If you linked
your program against library /usr/lib/libthread.so, you cannot move the library to a
different directory unless you specified it to the linker. Otherwise, the program will fail at runtime
when it calls a function in the library, with an error message like:
ld.so.1: main: fatal: libthread.so: can't open file: errno=2
This is also an issue when you are executing on a different machine than the one on which you
compiled. The execution machine must have all the libraries that you linked with, and must have them
in the directories where you told the linker they would be. For the standard system libraries, this isn't a
problem.
The main reason for using shared libraries is to get the benefit of the ABI—freeing your software from
the need to recompile with each new release of a library or OS. As a side benefit, there are also overall
system performance advantages.
Anyone can create a static or dynamic library. You simply compile some code without a main routine,
and process the resulting .o files with the correct utility—"ar" for static libraries, or "ld" for dynamic libraries.
NOTE:
1.A dynamically linked library is created by the link editor, ld. The conventional file extension for a
dynamic library is ".so" meaning "shared object"—every program linked against this library shares the
same one copy, in contrast to static linking, in which everyone is (wastefully) given their own copy of
the contents of the library. In its simplest form, a dynamic library can be created by using the -G
option to cc, like this:
2.Static libraries are known as archives and they are created and updated by the ar—for archive—
utility. The ar utility is misnamed; if truth in advertising applied to software, it would really be called
something like glue_files_together or even static_library_updater.
Convention dictates that static libraries have a ".a" extension on their filename
Reference: Expert C Programming
No comments:
Post a Comment