By default, the runtime linker knows of only one standard place to look for libraries, /usr/lib when processing 32-bit objects, and /usr/lib/64 when processing 64-bit objects. All other directories to be searched must be added to the runtime linker's search path explicitly.
By default, libraries are located in /usr/local/lib, /usr/local/lib64, /usr/lib and /usr/lib64; system startup libraries are in /lib and /lib64. Programmers can, however, install libraries in custom locations. The library path can be defined in /etc/ld.
ldconfig is a utility that indexes shared object names to simplify loading on shared object libraries by executables. It scans standard directories and those found in the ld. so. conf configuration file and stores its index in ld.
With GCC command Note: gcc looks for the libraries' names from left to right and stops finding when it matches the first library with the searching term. You also can show the library search directories list by adding the verbose flag -v when linking.
You can do this by executing the following command:
ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012
gcc passes a few extra -L paths to the linker, which you can list with the following command:
gcc -print-search-dirs | sed '/^lib/b 1;d;:1;s,/[^/.][^/]*/\.\./,/,;t 1;s,:[^=]*=,:;,;s,;,; ,g' | tr \; \\012
The answers suggesting to use ld.so.conf and ldconfig are not correct because they refer to the paths searched by the runtime dynamic linker (i.e. whenever a program is executed), which is not the same as the path searched by ld (i.e. whenever a program is linked).
On Linux, you can use ldconfig
, which maintains the ld.so configuration and cache, to print out the directories search by ld.so
with
ldconfig -v 2>/dev/null | grep -v ^$'\t'
ldconfig -v
prints out the directories search by the linker (without a leading tab) and the shared libraries found in those directories (with a leading tab); the grep
gets the directories. On my machine, this line prints out
/usr/lib64/atlas:
/usr/lib/llvm:
/usr/lib64/llvm:
/usr/lib64/mysql:
/usr/lib64/nvidia:
/usr/lib64/tracker-0.12:
/usr/lib/wine:
/usr/lib64/wine:
/usr/lib64/xulrunner-2:
/lib:
/lib64:
/usr/lib:
/usr/lib64:
/usr/lib64/nvidia/tls: (hwcap: 0x8000000000000000)
/lib/i686: (hwcap: 0x0008000000000000)
/lib64/tls: (hwcap: 0x8000000000000000)
/usr/lib/sse2: (hwcap: 0x0000000004000000)
/usr/lib64/tls: (hwcap: 0x8000000000000000)
/usr/lib64/sse2: (hwcap: 0x0000000004000000)
The first paths, without hwcap
in the line, are either built-in or read from /etc/ld.so.conf.
The linker can then search additional directories under the basic library search path, with names like sse2
corresponding to additional CPU capabilities.
These paths, with hwcap
in the line, can contain additional libraries tailored for these CPU capabilities.
One final note: using -p
instead of -v
above searches the ld.so
cache instead.
I'm not sure that there is any option for simply printing the full effective search path.
But: the search path consists of directories specified by -L
options on the command line, followed by directories added to the search path by SEARCH_DIR("...")
directives in the linker script(s). So you can work it out if you can see both of those, which you can do as follows:
If you're invoking ld
directly:
-L
options are whatever you've said they are.--verbose
option. Look for the SEARCH_DIR("...")
directives, usually near the top of the output. (Note that these are not necessarily the same for every invocation of ld
-- the linker has a number of different built-in default linker scripts, and chooses between them based on various other linker options.)If you're linking via gcc
:
-v
option to gcc
so that it shows you how it invokes the linker. In fact, it normally does not invoke ld
directly, but indirectly via a tool called collect2
(which lives in one of its internal directories), which in turn invokes ld
. That will show you what -L
options are being used.-Wl,--verbose
to the gcc
options to make it pass --verbose
through to the linker, to see the linker script as described above.The most compatible command I've found for gcc and clang on Linux (thanks to armando.sano):
$ gcc -m64 -Xlinker --verbose 2>/dev/null | grep SEARCH | sed 's/SEARCH_DIR("=\?\([^"]\+\)"); */\1\n/g' | grep -vE '^$'
if you give -m32
, it will output the correct library directories.
Examples on my machine:
for g++ -m64
:
/usr/x86_64-linux-gnu/lib64
/usr/i686-linux-gnu/lib64
/usr/local/lib/x86_64-linux-gnu
/usr/local/lib64
/lib/x86_64-linux-gnu
/lib64
/usr/lib/x86_64-linux-gnu
/usr/lib64
/usr/local/lib
/lib
/usr/lib
for g++ -m32
:
/usr/i686-linux-gnu/lib32
/usr/local/lib32
/lib32
/usr/lib32
/usr/local/lib/i386-linux-gnu
/usr/local/lib
/lib/i386-linux-gnu
/lib
/usr/lib/i386-linux-gnu
/usr/lib
The question is tagged Linux, but maybe this works as well under Linux?
gcc -Xlinker -v
Under Mac OS X, this prints:
@(#)PROGRAM:ld PROJECT:ld64-224.1
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 armv6m armv7m armv7em
Library search paths:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib
Framework search paths:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/
[...]
The -Xlinker
option of gcc
above just passes -v
to ld
. However:
ld -v
doesn't print the search path.
Mac version: $ ld -v 2, don't know how to get detailed paths. output
Library search paths:
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/
/System/Library/Frameworks/
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With