ExtUtils::Liblist - determine libraries to use and how to use them
require ExtUtils::Liblist;
ExtUtils::Liblist::ext($self, $potential_libs, $verbose);
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:
- For static extensions
by the ld command when the perl binary is linked with the extension library. See
EXTRALIBS below.
- For dynamic extensions
by the ld command when the shared object is built/linked. See
LDLOADLIBS below.
- For dynamic extensions
by the DynaLoader when the shared object is loaded. See
BSLOADLIBS below.
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.
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.
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.
This module deals with a lot of system dependencies and has quite a few
architecture specific ifs in the code.
The version of ext()
which is executed under
VMS differs from the Unix-OS/2 version in several
respects:
-
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.
-
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.
-
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.
-
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.
The version of ext()
which is executed under Win32 differs
from the Unix-OS/2 version in several respects:
-
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.
-
Entries cannot be plain object files, as many Win32 compilers will not
handle object files in the place of libraries.
-
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).
-
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.
-
LDLOADLIBS and
EXTRALIBS are always identical under Win32, and
BSLOADLIBS and
LD_RUN_PATH are always empty (this may change in future).
MakeMaker