SHLICC(1) BSD Reference Manual SHLICC(1)NAME
shlicc, shlicc++ - link programs for use with static shared libraries
SYNOPSISshlicc [-Bstatic] [-map shlib.map] ... [-larchive] ...
DESCRIPTION
The shlicc program works almost exactly the same way as cc(1) (q.v.), but
it arranges to link and load static shared libraries instead of archive
libraries or dynamic shared libraries. Binaries that use shared li-
braries may be substantially smaller than binaries that link in normal
archive libraries, since shared libraries are copied into memory only
when a program runs, while normal libraries are (selectively) copied into
a program when the program is built. Binaries that link with static
shared libraries are also a bit smaller and faster than programs that
link with dynamic shared libraries, although the static shared libraries
are not as flexible (see BUGS below). Shlicc invokes cc(1) to compile
all C and assembly programs; it only behaves differently from cc(1) when
asked to link a binary. The alias shlicc++ compiles programs with
g++(1).
The shlicc program passes most option and file arguments on to the com-
piler and linker, but does recognize a few itself:
-Bstatic
Force shlicc to behave exactly like cc(1); this is useful when
shlicc is your standard C compiler interface and you need to com-
pile a program without using shared libraries.
-larchive
Perform linking with the given library in the same style as
cc(1), but use a shared library in place of a normal archive li-
brary if one is available. When linking, shlicc decides which
shared libraries it can use based on the shlib.map file. When
shlicc sees ld(1) linker options like -larchive, it scans the
shlib.map file to find the corresponding shared library for
archive and substitutes an appropriate option, usually something
like -larchive_s.*. From the list of -l options, shlicc generates
a table of shared library names and addresses that it then links
into the new binary. Shlicc also links in a different C run-time
startup file, shlicrt0.o, which provides library table informa-
tion to the bootstrap code when the new binary runs.
-map shlib.map
Use an alternate shlib.map file (see mkshlib(8)). If the
shlib.map argument does not contain a `/' character and is not
found to be a readable file, shlicc will try prepending the
string /etc/shlib.map. to it. This option overrides the
SHLIB_MAP variable (see below).
-r In addition to passing this flag to the linker, shlicc will sus-
pend its normal practices of building a shared library table and
linking in the shlicrt0.o file. It will still link against the
default list of libraries.
Following the example of the compilers, shlicc will implicitly link
against a default set of libraries. The shlicc interface implicitly
links with the shared C library -lc, while the shlicc++ interface also
links with the shared libraries corresponding to -lstdc++, -lm and -lgcc.
The system's default makefile headers in /usr/share/mk (see make(1)) use
shlicc to link programs.
FILES
/etc/shlib.map default table of shared libraries
/usr/lib/shlicrt0.o provides library table parameters to bootstrap code
ENVIRONMENT
SHLIB_MAP if set, gives an alternate shlib.map file
SEE ALSOcc(1), ld(1), mkshlib(8), shlib(8), shlist(8)BUGS
Dynamic shared libraries have many advantages over static shared li-
braries for ease of development and use, and for other features. The
cc(1) command links against dynamic shared libraries by default.
Binaries that link to static shared libraries have an `interpreter' but
no dynamic linking information; the interpreter is the shared C library,
which contains the bootstrap. Some programs can be confused by ELF exe-
cutable files that have an interpreter that is not the dynamic linker.
If a shared library is missing or corrupted or unreadable, programs will
print errors and dump core. The shared C library contains the library
loader routine; if it's hosed, then basically nothing works. If the
shared C library is deleted or mangled, you may need to boot from floppy
to restore it.
Turning on profiling turns off shared libraries. It didn't seem useful
to save space in binaries and then waste it by producing profiled shared
libraries that are hardly ever used.
Paths to static shared libraries are fixed by the /etc/shlib.map file at
compile time. There is no equivalent to LD_LIBRARY_PATH for static
shared libraries. Some people consider this to be a feature.
All instances of -lname are checked for shared library equivalents, and
are replaced if such equivalents are found. There is no way to override
this feature, even with a library path specified using -L.
There is no support for the dlopen(3) dynamic linking routines with stat-
ic shared libraries. If your application requires -ldl, you must use dy-
namic shared libraries.
This implementation has no automatic versioning. Library version changes
can be effected using the shlib.map file, however.
Statically linked shared libraries are cheap and fast, but they have some
serious limitations. In particular, if you write a substitute for a li-
brary routine and use the shared library, the calls to that routine from
within the shared library will use the library version, not your version.
This is particularly annoying with programs that provide their own mal-
loc(3) and free(3) routines; if you try to free memory that was generated
from (say) the shared strdup(3), your program can dump core. The easy
alternative in this case is to use dynamically linked shared libraries
instead. Also, if library code compares a pointer to a library function
that was passed to it from user code to the address of the library func-
tion, it will fail because the user code sees only the address of the
jump table slot. (Yes, some standard library code actually does this!)
The worst limitations of static shared libraries are the restrictions
that are required in order to maintain compatibility from build to build.
It's easy to break compatibility and not learn about it until programs
start to fail. See the BUGS section in the shlib(8) manual page for more
details.
BSD/OS October 11, 1999 2