ExtUtils::Liblist(P3e)rl
NNAAMMEE
ExtUtils::Liblist - determine libraries to use and how to
use them
SSYYNNOOPPSSIISS
require ExtUtils::Liblist;
ExtUtils::Liblist::ext($self, $potential_libs, $verbose);
DDEESSCCRRIIPPTTIIOONN
This utility takes a list of libraries in the form -llib1
-llib2 -llib3 and prints out lines suitable for inclusion
in an extension Makefile. Extra library paths may be
included with the form -L/another/path this will affect
the searches for all subsequent libraries.
It returns an array of four scalar values: EXTRALIBS,
BSLOADLIBS, LDLOADLIBS, and LD_RUN_PATH. Some of these
don't mean anything on VMS and Win32. See the details
about those platform specifics below.
Dependent libraries can be linked in one of three ways:
+o For static extensions
by the ld command when the perl binary is linked with
the extension library. See EXTRALIBS below.
+o For dynamic extensions
by the ld command when the shared object is
built/linked. See LDLOADLIBS below.
+o For dynamic extensions
by the DynaLoader when the shared object is loaded. See
BSLOADLIBS below.
EEXXTTRRAALLIIBBSS
List of libraries that need to be linked with when linking
a perl binary which includes this extension Only those
libraries that actually exist are included. These are
written to a file and used when linking perl.
LLDDLLOOAADDLLIIBBSS aanndd LLDD__RRUUNN__PPAATTHH
List of those libraries which can or must be linked into
the shared library when created using ld. These may be
static or dynamic libraries. LD_RUN_PATH is a colon
separated list of the directories in LDLOADLIBS. It is
passed as an environment variable to the process that
links the shared library.
BBSSLLOOAADDLLIIBBSS
List of those libraries that are needed but can be linked
in dynamically at run time on this platform.
SunOS/Solaris does not need this because ld records the
information (from LDLOADLIBS) into the object file. This
list is used to create a .bs (bootstrap) file.
PPOORRTTAABBIILLIITTYY
This module deals with a lot of system dependencies and
has quite a few architecture specific iiffs in the code.
VVMMSS iimmpplleemmeennttaattiioonn
The version of ext() which is executed under VMS differs
from the Unix-OS/2 version in several respects:
+o Input library and path specifications are accepted with
or without the -l and -L prefices used by Unix linkers.
If neither prefix is present, a token is considered a
directory to search if it is in fact a directory, and a
library to search for otherwise. Authors who wish their
extensions to be portable to Unix or OS/2 should use the
Unix prefixes, since the Unix-OS/2 version of ext()
requires them.
+o Wherever possible, shareable images are preferred to
object libraries, and object libraries to plain object
files. In accordance with VMS naming conventions, ext()
looks for files named libshr and librtl; it also looks
for liblib and liblib to accomodate Unix conventions
used in some ported software.
+o For each library that is found, an appropriate directive
for a linker options file is generated. The return
values are space-separated strings of these directives,
rather than elements used on the linker command line.
+o LDLOADLIBS and EXTRALIBS are always identical under VMS,
and BSLOADLIBS and LD_RIN_PATH are always empty.
In addition, an attempt is made to recognize several
common Unix library names, and filter them out or convert
them to their VMS equivalents, as appropriate.
In general, the VMS version of ext() should properly
handle input from extensions originally designed for a
Unix or VMS environment. If you encounter problems, or
discover cases where the search could be improved, please
let us know.
WWiinn3322 iimmpplleemmeennttaattiioonn
The version of ext() which is executed under Win32 differs
from the Unix-OS/2 version in several respects:
+o Input library and path specifications are accepted with
or without the -l and -L prefices used by Unix linkers.
-lfoo specifies the library foo.lib and -Ls:ome\dir
specifies a directory to look for the libraries that
follow. If neither prefix is present, a token is
considered a directory to search if it is in fact a
directory, and a library to search for otherwise. The
$Config{lib_ext} suffix will be appended to any entries
that are not directories and don't already have the
suffix. Authors who wish their extensions to be
portable to Unix or OS/2 should use the Unix prefixes,
since the Unix-OS/2 version of ext() requires them.
+o Entries cannot be plain object files, as many Win32
compilers will not handle object files in the place of
libraries.
+o If $potential_libs is empty, the return value will be
empty. Otherwise, the libraries specified by
$Config{libs} (see Config.pm) will be appended to the
list of $potential_libs. The libraries will be searched
for in the directories specified in $potential_libs as
well as in $Config{libpth}. For each library that is
found, a space-separated list of fully qualified
library pathnames is generated. You may specify an
entry that matches /:nodefault/i in $potential_libs to
disable the appending of default libraries found in
$Config{libs} (this should be only needed very rarely).
+o The libraries specified may be a mixture of static
libraries and import libraries (to link with DLLs).
Since both kinds are used pretty transparently on the
win32 platform, we do not attempt to distinguish between
them.
+o LDLOADLIBS and EXTRALIBS are always identical under
Win32, and BSLOADLIBS and LD_RUN_PATH are always empty
(this may change in future).
SSEEEE AALLSSOO
the ExtUtils::MakeMaker manpage