shlicc man page on BSDOS

Man page or keyword search:  
man Server   6284 pages
apropos Keyword Search (all sections)
Output format
BSDOS logo
[printable version]

SHLICC(1)		     BSD Reference Manual		     SHLICC(1)

NAME
     shlicc, shlicc++ - link programs for use with static shared libraries

SYNOPSIS
     shlicc [-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 ALSO
     cc(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
[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server BSDOS

List of man pages available for BSDOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net