ExtUtils::Liblist(pdf.php) - phpMan

ExtUtils::Liblist(3)  User Contributed Perl Documentation ExtUtils::Liblist(3)

NAME
       ExtUtils::Liblist - determine libraries to use and how to use them
SYNOPSIS
         require ExtUtils::Liblist;
         $MM->ext($potential_libs, $verbose, $need_names);
         # Usually you can get away with:
         ExtUtils::Liblist->ext($potential_libs, $verbose, $need_names)
DESCRIPTION
       This utility takes a list of libraries in the form "-llib1 -llib2
       -llib3" and returns 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 or five scalar values: EXTRALIBS,
       BSLOADLIBS, LDLOADLIBS, LD_RUN_PATH, and, optionally, a reference to
       the array of the filenames of actual libraries.  Some of these don't
       mean anything unless on Unix.  See the details about those platform
       specifics below.  The list of the filenames is returned only if
       $need_names argument is true.
       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 at build/link time
         by the ld command when the shared object is built/linked. See
         LDLOADLIBS below.
       o For dynamic extensions at load time
         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.
       Fedora extension: This generation of LD_RUN_PATH is disabled by
       default.  To use the generated LD_RUN_PATH for all links, set the
       USE_MM_LD_RUN_PATH MakeMaker object attribute / argument, (or set the
       $USE_MM_LD_RUN_PATH environment variable).
   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 "if"s in the code.
   VMS implementation
       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" prefixes 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 accommodate 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 contains both the libraries found based on $potential_libs
         and the CRTLs, if any, specified in Config.pm.  EXTRALIBS contains
         just those libraries found based on $potential_libs.  BSLOADLIBS and
         LD_RUN_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:
       o If $potential_libs is empty, the return value will be empty.
         Otherwise, the libraries specified by $Config{perllibs} (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, $Config{libpth}, and in
         "$Config{installarchlib}/CORE".  For each library that is found,  a
         space-separated list of fully qualified library pathnames is
         generated.
       o Input library and path specifications are accepted with or without
         the "-l" and "-L" prefixes used by Unix linkers.
         An entry of the form "-La:\foo" specifies the "a:\foo" directory to
         look for the libraries that follow.
         An entry of the form "-lfoo" specifies the library "foo", which may
         be spelled differently depending on what kind of compiler you are
         using.  If you are using GCC, it gets translated to "libfoo.a", but
         for other win32 compilers, it becomes "foo.lib".  If no files are
         found by those translated names, one more attempt is made to find
         them using either "foo.a" or "libfoo.lib", depending on whether GCC
         or some other win32 compiler is being used, respectively.
         If neither the "-L" or "-l" prefix is present in an entry, the entry
         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.
         Note that the "-L" and "-l" prefixes are not required, but authors
         who wish their extensions to be portable to Unix or OS/2 should use
         the 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 Entries in $potential_libs beginning with a colon and followed by
         alphanumeric characters are treated as flags.  Unknown flags will be
         ignored.
         An entry that matches "/:nodefault/i" disables the appending of
         default libraries found in $Config{perllibs} (this should be only
         needed very rarely).
         An entry that matches "/:nosearch/i" disables all searching for the
         libraries specified after it.  Translation of "-Lfoo" and "-lfoo"
         still happens as appropriate (depending on compiler being used, as
         reflected by $Config{cc}), but the entries are not verified to be
         valid files or directories.
         An entry that matches "/:search/i" reenables searching for the
         libraries specified after it.  You can put it at the end to enable
         searching for default libraries specified by $Config{perllibs}.
       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).
       o You must make sure that any paths and path components are properly
         surrounded with double-quotes if they contain spaces. For example,
         $potential_libs could be (literally):
                 "-Lc:\Program Files\vc\lib" msvcrt.lib "la test\foo bar.lib"
         Note how the first and last entries are protected by quotes in order
         to protect the spaces.
       o Since this module is most often used only indirectly from extension
         "Makefile.PL" files, here is an example "Makefile.PL" entry to add a
         library to the build process for an extension:
                 LIBS => ['-lgl']
         When using GCC, that entry specifies that MakeMaker should first look
         for "libgl.a" (followed by "gl.a") in all the locations specified by
         $Config{libpth}.
         When using a compiler other than GCC, the above entry will search for
         "gl.lib" (followed by "libgl.lib").
         If the library happens to be in a location not in $Config{libpth},
         you need:
                 LIBS => ['-Lc:\gllibs -lgl']
         Here is a less often used example:
                 LIBS => ['-lgl', ':nosearch -Ld:\mesalibs -lmesa -luser32']
         This specifies a search for library "gl" as before.  If that search
         fails to find the library, it looks at the next item in the list. The
         ":nosearch" flag will prevent searching for the libraries that
         follow, so it simply returns the value as "-Ld:\mesalibs -lmesa
         -luser32", since GCC can use that value as is with its linker.
         When using the Visual C compiler, the second item is returned as
         "-libpath:d:\mesalibs mesa.lib user32.lib".
         When using the Borland compiler, the second item is returned as
         "-Ld:\mesalibs mesa.lib user32.lib", and MakeMaker takes care of
         moving the "-Ld:\mesalibs" to the correct place in the linker command
         line.
SEE ALSO
       ExtUtils::MakeMaker

perl v5.16.3                      2014-06-10              ExtUtils::Liblist(3)