Codebase list libffi-checklib-perl / HEAD
HEAD

Tree @HEAD (Download .tar.gz)

NAME

    FFI::CheckLib - Check that a library is available for FFI

VERSION

    version 0.31

SYNOPSIS

     use FFI::CheckLib;
     
     check_lib_or_exit( lib => 'jpeg', symbol => 'jinit_memory_mgr' );
     check_lib_or_exit( lib => [ 'iconv', 'jpeg' ] );
     
     # or prompt for path to library and then:
     print "where to find jpeg library: ";
     my $path = <STDIN>;
     check_lib_or_exit( lib => 'jpeg', libpath => $path );

DESCRIPTION

    This module checks whether a particular dynamic library is available
    for FFI to use. It is modeled heavily on Devel::CheckLib, but will find
    dynamic libraries even when development packages are not installed. It
    also provides a find_lib function that will return the full path to the
    found dynamic library, which can be feed directly into FFI::Platypus or
    another FFI system.

    Although intended mainly for FFI modules via FFI::Platypus and similar,
    this module does not actually use any FFI to do its detection and
    probing. This module does not have any non-core runtime dependencies.
    The test suite does depend on Test2::Suite.

FUNCTIONS

    All of these take the same named parameters and are exported by
    default.

 find_lib

     my(@libs) = find_lib(%args);

    This will return a list of dynamic libraries, or empty list if none
    were found.

    [version 0.05]

    If called in scalar context it will return the first library found.

    Arguments are key value pairs with these keys:

    lib

      Must be either a string with the name of a single library or a
      reference to an array of strings of library names. Depending on your
      platform, CheckLib will prepend lib or append .dll or .so when
      searching.

      [version 0.11]

      As a special case, if * is specified then any libs found will match.

    libpath

      A string or array of additional paths to search for libraries.

    systempath

      [version 0.11]

      A string or array of system paths to search for instead of letting
      FFI::CheckLib determine the system path. You can set this to [] in
      order to not search any system paths.

    symbol

      A string or a list of symbol names that must be found.

    verify

      A code reference used to verify a library really is the one that you
      want. It should take two arguments, which is the name of the library
      and the full path to the library pathname. It should return true if
      it is acceptable, and false otherwise. You can use this in
      conjunction with FFI::Platypus to determine if it is going to meet
      your needs. Example:

       use FFI::CheckLib;
       use FFI::Platypus;
       
       my($lib) = find_lib(
         lib => 'foo',
         verify => sub {
           my($name, $libpath) = @_;
       
           my $ffi = FFI::Platypus->new;
           $ffi->lib($libpath);
       
           my $f = $ffi->function('foo_version', [] => 'int');
       
           return $f->call() >= 500; # we accept version 500 or better
         },
       );

    recursive

      [version 0.11]

      Recursively search for libraries in any non-system paths (those
      provided via libpath above).

    try_linker_script

      [version 0.24]

      Some vendors provide .so files that are linker scripts that point to
      the real binary shared library. These linker scripts can be used by
      gcc or clang, but are not directly usable by FFI::Platypus and
      friends. On select platforms, this options will use the linker
      command (ld) to attempt to resolve the real .so for non-binary files.
      Since there is extra overhead this is off by default.

      An example is libyaml on Red Hat based Linux distributions. On Debian
      these are handled with symlinks and no trickery is required.

    alien

      [version 0.25]

      If no libraries can be found, try the given aliens instead. The Alien
      classes specified must provide the Alien::Base interface for dynamic
      libraries, which is to say they should provide a method called
      dynamic_libs that returns a list of dynamic libraries.

      [version 0.28]

      In 0.28 and later, if the Alien is not installed then it will be
      ignored and this module will search in system or specified
      directories only. This module will still throw an exception, if the
      Alien doesn't look like a module name or if it does not provide a
      dynamic_libs method (which is implemented by all Alien::Base
      subclasses).

      [version 0.30] [breaking change]

      Starting with version 0.30, libraries provided by Aliens is preferred
      over the system libraries. The original thinking was that you want to
      prefer the system libraries because they are more likely to get
      patched with regular system updates. Unfortunately, the reason a
      module needs to install an Alien is likely because the system library
      is not new enough, so we now prefer the Aliens instead.

 assert_lib

     assert_lib(%args);

    This behaves exactly the same as find_lib, except that instead of
    returning empty list of failure it throws an exception.

 check_lib_or_exit

     check_lib_or_exit(%args);

    This behaves exactly the same as assert_lib, except that instead of
    dying, it warns (with exactly the same error message) and exists. This
    is intended for use in Makefile.PL or Build.PL

 find_lib_or_exit

    [version 0.05]

     my(@libs) = find_lib_or_exit(%args);

    This behaves exactly the same as find_lib, except that if the library
    is not found, it will call exit with an appropriate diagnostic.

 find_lib_or_die

    [version 0.06]

     my(@libs) = find_lib_or_die(%args);

    This behaves exactly the same as find_lib, except that if the library
    is not found, it will die with an appropriate diagnostic.

 check_lib

     my $bool = check_lib(%args);

    This behaves exactly the same as find_lib, except that it returns true
    (1) on finding the appropriate libraries or false (0) otherwise.

 which

    [version 0.17]

     my $path = which($name);

    Return the path to the first library that matches the given name.

    Not exported by default.

 where

    [version 0.17]

     my @paths = where($name);

    Return the paths to all the libraries that match the given name.

    Not exported by default.

 has_symbols

    [version 0.17]

     my $bool = has_symbols($path, @symbol_names);

    Returns true if all of the symbols can be found in the dynamic library
    located at the given path. Can be useful in conjunction with verify
    with find_lib above.

    Not exported by default.

 system_path

    [version 0.20]

     my $path = FFI::CheckLib::system_path;

    Returns the system path as a list reference. On some systems, this is
    PATH on others it might be LD_LIBRARY_PATH on still others it could be
    something completely different. So although you may add items to this
    list, you should probably do some careful consideration before you do
    so.

    This function is not exportable, even on request.

ENVIRONMENT

    FFI::CheckLib responds to these environment variables:

    FFI_CHECKLIB_PACKAGE

      On macOS platforms with Homebrew <http://brew.sh> and/or MacPorts
      <https://www.macports.org> installed, their corresponding lib paths
      will be automatically appended to $system_path. In case of having
      both managers installed, Homebrew will appear before.

      This behaviour can be overridden using the environment variable
      FFI_CHECKLIB_PACKAGE.

      Allowed values are:

      - none: Won't use either Homebrew's path nor MacPorts - homebrew:
      Will append $(brew --prefix)/lib to the system paths - macports: Will
      append port's default lib path

      A comma separated list is also valid:

       export FFI_CHECKLIB_PACKAGE=macports,homebrew

      Order matters. So in this example, MacPorts' lib path appears before
      Homebrew's path.

    FFI_CHECKLIB_PATH

      List of directories that will be considered by FFI::CheckLib as
      additional "system directories". They will be searched before other
      system directories but after libpath. The variable is colon separated
      on Unix and semicolon separated on Windows. If you use this variable,
      FFI_CHECKLIB_PACKAGE will be ignored.

    PATH

      On Windows the PATH environment variable will be used as a search
      path for libraries.

    On some operating systems LD_LIBRARY_PATH, DYLD_LIBRARY_PATH,
    DYLD_FALLBACK_LIBRARY_PATH or others may be used as part of the search
    for dynamic libraries and may be used (indirectly) by FFI::CheckLib as
    well.

FAQ

    Why not just use dlopen?

      Calling dlopen on a library name and then dlclose immediately can
      tell you if you have the exact name of a library available on a
      system. It does have a number of drawbacks as well.

      No absolute or relative path

	It only tells you that the library is somewhere on the system, not
	having the absolute or relative path makes it harder to generate
	useful diagnostics.

      POSIX only

	This doesn't work on non-POSIX systems like Microsoft Windows. If
	you are using a POSIX emulation layer on Windows that provides
	dlopen, like Cygwin, there are a number of gotchas there as well.
	Having a layer written in Perl handles this means that developers
	on Unix can develop FFI that will more likely work on these
	platforms without special casing them.

      inconsistent implementations

	Even on POSIX systems you have inconsistent implementations.
	OpenBSD for example don't usually include symlinks for .so files
	meaning you need to know the exact .so version.

      non-system directories

	By default dlopen only works for libraries in the system paths.
	Most platforms have a way of configuring the search for different
	non-system paths, but none of them are portable, and are usually
	discouraged anyway. Alien and friends need to do searches for
	dynamic libraries in non-system directories for share installs.

    My 64-bit Perl is misconfigured and has 32-bit libraries in its search
    path. Is that a bug in FFI::CheckLib?

      Nope.

    The way FFI::CheckLib is implemented it won't work on AIX, HP-UX,
    OpenVMS or Plan 9.

      I know for a fact that it doesn't work on AIX as currently
      implemented because I used to develop on AIX in the early 2000s, and
      I am aware of some of the technical challenges. There are probably
      other systems that it won't work on. I would love to add support for
      these platforms. Realistically these platforms have a tiny market
      share, and absent patches from users or the companies that own these
      operating systems (patches welcome), or hardware / CPU time
      donations, these platforms are unsupportable anyway.

SEE ALSO

    FFI::Platypus

      Call library functions dynamically without a compiler.

    Dist::Zilla::Plugin::FFI::CheckLib

      Dist::Zilla plugin for this module.

AUTHOR

    Author: Graham Ollis <plicease@cpan.org>

    Contributors:

    Bakkiaraj Murugesan (bakkiaraj)

    Dan Book (grinnz, DBOOK)

    Ilya Pavlov (Ilya, ILUX)

    Shawn Laffan (SLAFFAN)

    Petr Písař (ppisar)

    Michael R. Davis (MRDVT)

    Shawn Laffan (SLAFFAN)

    Carlos D. Álvaro (cdalvaro)

COPYRIGHT AND LICENSE

    This software is copyright (c) 2014-2022 by Graham Ollis.

    This is free software; you can redistribute it and/or modify it under
    the same terms as the Perl 5 programming language system itself.