ExtUtils::Liblist
Section: Perl Programmers Reference Guide
(3)
Updated: perl 5.004, patch 55
Index
Return to Main Contents
NAME
ExtUtils::Liblist - determine libraries to use and how to use them
SYNOPSIS
require ExtUtils::Liblist;
ExtUtils::Liblist::ext($self, $potential_libs, $verbose);
DESCRIPTION
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.
EXTRALIBS
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.
LDLOADLIBS and LD_RUN_PATH
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.
BSLOADLIBS
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.
PORTABILITY
This module deals with a lot of system dependencies and has quite a
few architecture specific ifs in the code.
VMS implementation
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.
Win32 implementation
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).
SEE ALSO
the ExtUtils::MakeMaker manpage
Index
- NAME
-
- SYNOPSIS
-
- DESCRIPTION
-
- EXTRALIBS
-
- LDLOADLIBS and LD_RUN_PATH
-
- BSLOADLIBS
-
- PORTABILITY
-
- VMS implementation
-
- Win32 implementation
-
- SEE ALSO
-
This document was created by
man2html,
using the manual pages.
Time: 23:58:14 GMT, February 15, 2023