ARG-1 ARG-2 ARG-3
[$obj or Class "ExtUtils::Liblist"]->ext($potential_libs, $verbose, $need_names);
So $_[1] (ARG-2 ) and $_[2] (ARG-3) are BOOLEANS.
The POD says:
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.
The version of ext() which is executed under Win32 differs from the Unix-OS/2 version in several respects:
If
$potential_libs
is empty, the return value will be empty. Otherwise, the libraries specified by$Config{perllibs}
will be appended (see Config.pm).# I<$potential_libs> is ARG-1. Who would call ext() with an empty arg 1? Why # that design? # Telling people to go look at "Config.pm" for illumination concerning # I<perllibs> is unhelpful. There are too many cross references in this # document. It makes it extremely difficult to get a working understanding of # how this all works, fits together. # What is an actual example of C<$Config{perllibs}>? $ perl -V:perllibs perllibs='-lmsvcrt -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32'; # It seems like on Win32, perllibs is a conflation of the "C library" (what # would be -lc for gcc on a GNU/Linux system), and libraries implementing the # Win32 API.
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.# $Config{libpth} eh. Ok, what does an example of that from an actual Win32 perl look like?: $ perl -V:libpth libpth='C:\strawberry\c\lib C:\strawberry\c\i686-w64-mingw32\lib'; $ perl -V:libpth libpth='C:\camelbox\lib'; # It seems advisable to add those to ARG-1 before calling ext() in the first place. # $ perl -V:installarchlib installarchlib='C:\strawberry\perl\lib'; # That makes C<$Config{installarchlib}/CORE> C<C:\strawberry\perl\lib/CORE>. $ perl -V:installarchlib installarchlib='C:\camelbox\lib'; # Ouch. That makes C<libpth> and C<installarchlib> the same. That has got me thinking that any reasonable code used in a Makefile.PL that calls ext() ought to vett the dirs in those Config keys first.
For each library that is found, a space-separated list of fully qualified library pathnames is generated.
# And right there is a good reason why a general rule like "do not install perl to a path with (embedded) spaces," is a good rule.
LDLOADLIBS and EXTRALIBS are always identical under Win32, and BSLOADLIBS and LD_RUN_PATH are always empty (this may change in future).
Entries in
$potential_libs
beginning with a colon and followed by alphanumeric characters are treated as flags. Unknown flags will be ignored.# Sounds like a kludge for the MSVC compiler.
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}
.# It sounds like one would often want to use C<:nosearch>. The extra noise # that EU::MM makes when an external library dependency is being located is # often useless; it merely emits a new-user-unfriendly warning and then goes # on to allow compilation to fail in the code-building state.
Since this module is most often used only indirectly from extension
Makefile.PL
files, here is an exampleMakefile.PL
entry to add a library to the build process for an extension:LIBS => ['-lgl'] # It is using LIBS that triggers the EU::MM mechanism to attempt to use # EU::LibList. One way to avoid using EU::LibList might be to scrupulously # avoid using LIBS.