In article <NEWTNews.822421599.1020.us009...@interramp.com>,
> What command line options are necessary to link with shared libraries
> in Release 5 ? What are the differences between shared libraries and
> DLLs ? What is /shlib ?
I will append an article that should answer your questions.
> Since SCO no longer supplies manuals or support at a reasonable cost,
> and since we have lost enough customers with this OSE5 fiasco that we
> hope to port our applications to other platforms. Does anyone have
> favorite alternatives you can recommend ?
I have to question the rationale behind your porting strategy. You are
seriously going to port to the favourite OS of some random people on
Usenet without even telling them what the applications are? Come on!
I also have to take some exception to the "fiasco" comment--the
reaction to OpenServer 5 has been overwhelmingly positive, especially
from software developers. If you have any details that might clarify
your inflammatory comment, we would be most interested to hear them.
Having said that, we would hate to lose a customer (even a bellicose
one), and I hope the following article reduces the frustration you are
having with DLLs, and by extension (it would appear) with OpenServer
Dynamically Linked Libraries on SCO OpenServer 5.0
by Murray Nesbitt (m...@sco.com), SCO Canada Inc.
From a software developer's point of view, one of the most important
new features of the SCO OpenServer 5.0 System is the ability to create
and use dynamically linked libraries (DLLs). DLLs make it possible to
significantly reduce the disk and memory requirements of your
applications. Additionally, DLLs make it possible to fix or enhance a
library without the need to relink programs that depend on that
To fully appreciate the benefits of dynamic linking, we must first look
at the process of traditional (static) linking. When a program
containing calls to library routines is statically linked, the object
files containing those routines are copied from an archive library
(e.g., /usr/lib/libc.a) into the executable at link-time. External
references are resolved when the program is created. This means that
the code for library routines used by many programs is stored on disk
in each of the programs, even though the code is the same in each
program. Furthermore, independent copies of the same code are
executing in memory when these programs are executed.
When the same program is dynamically linked, objects are mapped into
the virtual address space of the process at run-time, i.e., external
references are resolved at run-time. Dynamically linked programs share
library code, and thus typically require fewer disk and memory
resources than their statically linked equivalents.
Another major benefit of dynamic linking is the ability to fix or
enhance libraries without the need to relink programs that depend on
them. After a bug has been fixed in a DLL, the new DLL simply replaces
the previous version. Programs that dynamically link to that DLL remain
unmodified, but get the benefit of the bug fix. This ability to update
without relinking executables can be a great boon during the
development cycle, as the time required to rebuild large applications
after small code changes can be significantly reduced.
Software developers familiar with the use of static shared libraries
will notice that many of these benefits are gained when using existing
static shared library technology. However, DLLs and dynamically linked
programs can be created by simply adding one or two options to the
compiler. In contrast, static shared libraries have a number of
requirements: a hard-coded library pathname; programs other than the
compiler must be used; certain data files must be kept synchronized
with code. Static shared libraries are, in general, much more
difficult to create and maintain than DLLs. Because of the added
complexity involved in creating and maintaining them, static shared
libraries are also more prone to problems as the library evolves.
Finally, as shown in the example below, dynamically linked programs are
able to load new DLLs at run-time, a capability that does not exist
with static shared libraries.
Dynamically Linking Your Program
To enable dynamic linking in your program, use the "-dy -K PIC" options
to "cc". These options instruct the compiler to generate ELF objects
(which are required for dynamic linking), and instruct it to use the
dynamic version of a library (e.g., /usr/lib/libc.so) instead of the
static version (/usr/lib/libc.a). The "-K PIC" option instructs the
compiler to generate "position-independent code", i.e., code that
executes correctly at any virtual address. This is optional, but
strongly recommended, because it makes a program less vulnerable to
future changes in the memory layout of the DLLs (for example, a change
in the size of an exported data structure), at the price of a slight
decrease in run-time performance.
The command to create a "hello world" program using DLLs is:
% cc -dy -K PIC -o hello hello.c
This command creates an ELF executable file that uses the dynamically
linked version of libc. When the same program is statically linked
(i.e., compiled without "-dy") and compared with the dynamically linked
version, the savings in disk space are apparent.
The decision to dynamically link a program is not always
straightforward. Although the code (or "text") sections of a DLL are
shared between processes, the data sections are not. Each program
using a DLL will be allocated its own copy of the library's data
section. If a library's data section is larger than the parts of the
code and data sections you actually use in your program, it may be
better to statically link to the library rather than include the
library's entire data section via dynamically linking.
For example, let's say you use a self-contained, 500 byte routine from
a library, and this library has a 5000 byte data section. Clearly, it
would be preferable to just statically link in the routine, adding 500
bytes to the size of your program, because linking in the data section
via dynamic linking would add 5000 bytes. Judicious use of the
"size(CP)" command will reveal these cases.
Because each program gets a copy of the data section of a DLL, library
writers should make an effort to minimize the size of the data section
of their libraries by using automatic variables rather than global
variables, when possible.
To create a dynamically linked version of a library, use the "-G" option
along with the "-dy -K PIC" options (as explained earlier), and rename the
library, using the suffix ".so" (rather than the standard ".a") to conform to
the conventions used by the "-l" option of "cc".
% cc -dy -K PIC -G -o libfoo.so foo1.c foo2.c
To link to this library, use the "-dy -K PIC" options to cc, as
explained earlier. No other command changes are needed:
% cc -dy -K PIC -o footest foo.c -L. -lfoo
Because dynamically linked libraries are not appropriate in all
situations, it's a good idea for library vendors to provide statically
linked versions of their libraries in addition to their dynamically
Running Dynamically Linked Programs
When you execute a dynamically linked program, the kernel does not
directly execute the program. Instead, it invokes a dynamic linker,
which reads information (such as required DLLs) from the dynamically
linked binary before invoking it.
The dynamic linker needs to know where to find any DLLs the program
uses. There are a number of ways to indicate the directories to be
searched, most of which are beyond the scope of this article, and are
suboptimal in general, because they require hard-coding the location
into the DLL and binaries that use it, thus defeating one of the
advantages of using DLLs. However, you should be aware of these
methods, as they are very appropriate in certain cases. For further
information about directory specification look at both the "-h" option
in the "cc(CP)" manual page and the environment variable "LD_RUN_PATH"
in the Programming Tools Guide.
The most flexible way to specify the directory search path is to use
the environment variable "LD_LIBRARY_PATH". This allows DLLs to be
moved to new locations without requiring a relink of the binaries that
% LD_LIBRARY_PATH=/home/dlls; export LD_LIBRARY_PATH
At run-time, the dynamic linker will search for any needed DLLs in the
directories specified via this variable, before it checks the default
location for DLLs, "/usr/lib".
If the dynamic linker cannot locate a DLL that a program needs, the
program will not execute. This fact should be kept in mind when
deciding whether to dynamically or statically link your application.
Some applications--backup/restore programs, for example--may not be
good candidates for dynamic linking.
For security reasons, great care should be taken in setting
"LD_LIBRARY_PATH" to point to "trusted" directories only. Ensure that
these directories are not writable by other users. In the interest of
security, the dynamic linker will not load DLLs from any directory
other than "/usr/lib" when executing setuid or setgid programs.
The "ldd(CP)" command (list dynamic dependencies) exists to check for
run-time compatibility between a program and the DLLs on which it
depends. When invoked with the name of a dynamically linked program as
an argument, "ldd" prints the pathnames of any DLLs the program uses,
and gives an error message if any of the DLLs cannot be located. If you
specify the "-r" option to "ldd", a diagnostic message gets printed for
any unresolved function or data references the program would encounter
if it executed.
Having covered the basics of dynamically linked libraries and programs,
we'll now look at a more esoteric use of this functionality: a
read more »