Linux find library command

find_library¶

This command is used to find a library. A cache entry, or a normal variable if NO_CACHE is specified, named by is created to store the result of this command. If the library is found the result is stored in the variable and the search will not be repeated unless the variable is cleared. If nothing is found, the result will be -NOTFOUND .

Specify one or more possible names for the library.

When using this to specify names with and without a version suffix, we recommend specifying the unversioned name first so that locally-built packages can be found before those provided by distributions.

Specify directories to search in addition to the default locations. The ENV var sub-option reads paths from a system environment variable.

Changed in version 3.24: On Windows platform, it is possible to include registry queries as part of the directories, using a dedicated syntax . Such specifications will be ignored on all other platforms.

Specify which registry views must be queried. This option is only meaningful on Windows platforms and will be ignored on other ones. When not specified, the TARGET view is used when the CMP0134 policy is NEW . Refer to CMP0134 for the default view when the policy is OLD .

Query the 64-bit registry. On 32-bit Windows, it always returns the string /REGISTRY-NOTFOUND .

Query both views ( 64 and 32 ) and generate a path for each.

Query both views ( 32 and 64 ) and generate a path for each.

Query the registry matching the architecture of the host: 64 on 64-bit Windows and 32 on 32-bit Windows.

Query the registry matching the architecture specified by the CMAKE_SIZEOF_VOID_P variable. If not defined, fall back to HOST view.

Query both views ( 32 and 64 ). The order depends on the following rules: If the CMAKE_SIZEOF_VOID_P variable is defined, use the following view depending on the content of this variable:

If the CMAKE_SIZEOF_VOID_P variable is not defined, rely on the architecture of the host:

Specify additional subdirectories to check below each directory location otherwise considered.

Specify a function() to be called for each candidate item found (a macro() cannot be provided, that will result in an error). Two arguments will be passed to the validator function: the name of a result variable, and the absolute path to the candidate item. The item will be accepted and the search will end unless the function sets the value in the result variable to false in the calling scope. The result variable will hold a true value when the validator function is entered.

function(my_check validator_result_var item) if(NOT item MATCHES . ) set($ FALSE PARENT_SCOPE) endif() endfunction() find_library (result NAMES . VALIDATOR my_check)

Note that if a cached result is used, the search is skipped and any VALIDATOR is ignored. The cached result is not required to pass the validation function.

Specify the documentation string for the cache entry.

The result of the search will be stored in a normal variable rather than a cache entry.

If the variable is already set before the call (as a normal or cache variable) then the search will not occur.

This option should be used with caution because it can greatly increase the cost of repeated configure steps.

Stop processing with an error message if nothing is found, otherwise the search will be attempted again the next time find_library is invoked with the same variable.

If NO_DEFAULT_PATH is specified, then no additional paths are added to the search. If NO_DEFAULT_PATH is not specified, the search process is as follows:

If called from within a find module or any other script loaded by a call to find_package() , search prefixes unique to the current package being found. See policy CMP0074 .

1. _ROOT CMake variable, where is the case-preserved package name.
2. _ROOT CMake variable, where is the upper-cased package name. See policy CMP0144 .

The package root variables are maintained as a stack, so if called from nested find modules or config packages, root paths from the parent’s find module or config package will be searched after paths from the current module or package. In other words, the search order would be _ROOT , ENV<_root> , _ROOT , ENV<_root> , etc. This can be skipped if NO_PACKAGE_ROOT_PATH is passed or by setting the CMAKE_FIND_USE_PACKAGE_ROOT_PATH to FALSE .

• /lib/ if CMAKE_LIBRARY_ARCHITECTURE is set, and /lib for each in the _ROOT CMake variable and the _ROOT environment variable if called from within a find module loaded by find_package()

• /lib/ if CMAKE_LIBRARY_ARCHITECTURE is set, and /lib for each in CMAKE_PREFIX_PATH
• CMAKE_LIBRARY_PATH
• CMAKE_FRAMEWORK_PATH

• /lib/ if CMAKE_LIBRARY_ARCHITECTURE is set, and /lib for each in CMAKE_PREFIX_PATH
• CMAKE_LIBRARY_PATH
• CMAKE_FRAMEWORK_PATH

• The directories in LIB and PATH .
• On Windows hosts: /lib/ if CMAKE_LIBRARY_ARCHITECTURE is set, and /lib for each /[s]bin in PATH , and /lib for other entries in PATH .

• /lib/ if CMAKE_LIBRARY_ARCHITECTURE is set, and /lib for each in CMAKE_SYSTEM_PREFIX_PATH
• CMAKE_SYSTEM_LIBRARY_PATH
• CMAKE_SYSTEM_FRAMEWORK_PATH

The platform paths that these variables contain are locations that typically include installed software. An example being /usr/local for UNIX based platforms.

New in version 3.16: Added CMAKE_FIND_USE__PATH variables to globally disable various search locations.

On macOS the CMAKE_FIND_FRAMEWORK and CMAKE_FIND_APPBUNDLE variables determine the order of preference between Apple-style and unix-style package components.

The CMake variable CMAKE_FIND_ROOT_PATH specifies one or more directories to be prepended to all other search directories. This effectively «re-roots» the entire search under given locations. Paths which are descendants of the CMAKE_STAGING_PREFIX are excluded from this re-rooting, because that variable is always a path on the host system. By default the CMAKE_FIND_ROOT_PATH is empty.

The CMAKE_SYSROOT variable can also be used to specify exactly one directory to use as a prefix. Setting CMAKE_SYSROOT also has other effects. See the documentation for that variable for more.

These variables are especially useful when cross-compiling to point to the root directory of the target environment and CMake will search there too. By default at first the directories listed in CMAKE_FIND_ROOT_PATH are searched, then the CMAKE_SYSROOT directory is searched, and then the non-rooted directories will be searched. The default behavior can be adjusted by setting CMAKE_FIND_ROOT_PATH_MODE_LIBRARY . This behavior can be manually overridden on a per-call basis using options:

Search in the order described above.

Search only the re-rooted directories and directories below CMAKE_STAGING_PREFIX .

The default search order is designed to be most-specific to least-specific for common use cases. Projects may override the order by simply calling the command multiple times and using the NO_* options:

find_library ( NAMES name PATHS paths. NO_DEFAULT_PATH) find_library ( NAMES name)

Once one of the calls succeeds the result variable will be set and stored in the cache so that no call will search again.

When more than one value is given to the NAMES option this command by default will consider one name at a time and search every directory for it. The NAMES_PER_DIR option tells this command to consider one directory at a time and search for all names in it.

Each library name given to the NAMES option is first considered as a library file name and then considered with platform-specific prefixes (e.g. lib ) and suffixes (e.g. .so ). Therefore one may specify library file names such as libfoo.a directly. This can be used to locate static libraries on UNIX-like systems.

If the library found is a framework, then will be set to the full path to the framework /A.framework . When a full path to a framework is used as a library, CMake will use a -framework A , and a -F to link the framework to the target.

If the CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX variable is set all search paths will be tested as normal, with the suffix appended, and with all matches of lib/ replaced with lib$/ . This variable overrides the FIND_LIBRARY_USE_LIB32_PATHS , FIND_LIBRARY_USE_LIBX32_PATHS , and FIND_LIBRARY_USE_LIB64_PATHS global properties.

If the FIND_LIBRARY_USE_LIB32_PATHS global property is set all search paths will be tested as normal, with 32/ appended, and with all matches of lib/ replaced with lib32/ . This property is automatically set for the platforms that are known to need it if at least one of the languages supported by the project() command is enabled.

If the FIND_LIBRARY_USE_LIBX32_PATHS global property is set all search paths will be tested as normal, with x32/ appended, and with all matches of lib/ replaced with libx32/ . This property is automatically set for the platforms that are known to need it if at least one of the languages supported by the project() command is enabled.

If the FIND_LIBRARY_USE_LIB64_PATHS global property is set all search paths will be tested as normal, with 64/ appended, and with all matches of lib/ replaced with lib64/ . This property is automatically set for the platforms that are known to need it if at least one of the languages supported by the project() command is enabled.

Источник

How to List Shared Libraries Used by Executables in Linux

Under a Linux operating system environment, the binary executables associated with the applications/programs you wish to run are directly linked with shared libraries loaded at runtime.

As a curious and evolving Linux user, you will be tempted to get an idea about these shared libraries involved/linked with the binary executables you are running during a normal program startup.

This article will walk us through several approaches to find out all shared libraries used by executables in Linux.

Brief Overview on Linux Libraries

A programmer or a user familiar with the programming world will define a library as pre-compiled code pieces/segments put together in an organized manner/format. The pre-compiled nature/attribute of a library makes it flexibly and easily reusable among different programs.

Under the Linux operating system architecture, we can categorize libraries as either static (static libraries) or shared (shared libraries).

Static libraries are statically bound to a specific program and are only accessible during the program’s compilation time. Shared libraries become active once a program is launched and will reside in memory during the program’s runtime duration.

How to Find a Program’s Shared Libraries in Linux

Before determining the shared libraries associated with your targeted program, you first need to know where the executable associated with your program is residing. In Linux, the location for your programs’ executables is usually inside the /usr/bin directory.

The column on the far-right lists the names of your programs’ executables.

Find Shared Libraries of Linux Program Using the ldd Command

The ldd command exists as a straightforward shell script that points to a program’s shared libraries. As per the screen capture above, let us for instance attempt to output the shared libraries associated with the anydesk application.

We could determine Anydesk’s executable’s location with the command:

To determine its shared libraries via the ldd command, we will execute:

As you can see, we have a list of numerous libraries associated with anydesk application. Please note that the ldd command tends to execute queried programs to retrieve shared libraries info. Therefore, only associate the command with trusted executables.

Find Program Shared Libraries Using objdump and grep Commands

The objdump command being part of the GNU Binutils package will focus on displaying the object files information whereas the grep command will list the program’s associated shared libraries.

Let us see what these commands will yield for a program like whois used for domain names info.

Next, find out the shared libraries of program.

$ objdump -p /usr/bin/whois | grep 'NEEDED'

As you can see, the whois domain lookup program executable is associated with two shared libraries.

Alternatively, you can also use the readelf command to retrieve shared information for the zip program’s executable.

$ whereis zip $ readelf --dynamic /usr/bin/zip | grep NEEDED

As per the output, the zip program executable is associated with two shared libraries.

Find Shared Libraries Using Awk Command

This option is ideal for a program that is already running. We first need to get it’s PID (Process ID). For instance, let’s say we have the Flameshot screen capture utility running.

To get its PID, we will run:

$ pgrep flameshot 45261 

Our /proc//maps file will be transformed to /proc/45261/maps. We can now combine this file with the awk command to retrieve Flameshot executable shared libraries as demonstrated below.

$ awk '$NF!~/\.so/  !a[$0]++' /proc/45261/maps

We are now well-acquainted in listing all shared libraries associated with program executables in Linux.

Источник