How to print the ld(linker) search path

Question

What is the way to print the search paths that in looked by ld in the order it searches.

Solution 1

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).

Solution 2

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.

Solution 3

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:

• The -L options are whatever you've said they are.
• To see the linker script, add the --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:

• You can pass the -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.
• You can add -Wl,--verbose to the gcc options to make it pass --verbose through to the linker, to see the linker script as described above.

Solution 4

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

Solution 5

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.

View more solutions

Comments

[fons]

He is asking about the linker (ld) and not the loader (ld.so)!

[Ari]

The --verbose option for the linker did the trick. Very helpful!

[Tomas]

How is it possible that if I set export LD_LIBRARY_PATH=/some/other/dir, it will not affect output of this command?! Seems it doesn't work 100%?

[thomasa88]

I was trying hard to figure out where the linker was looking and did not find SEARCH_DIR in the output. Turns out as I was using -T script my script completely replaced ld's default script and only looked where I pointed.

[kenn]

You hit the spot. I have a linking problem, during linking process linker finds manually installed libraries in /usr/local/.. which causes missing library error, and linking fails. I have to rename /usr/local everytime to exclude that search path. Is there a simple way to exclude or override /usr/local path?

[faken]

You can try to manually specify library paths with the -L option to GCC, which I think (not sure) will override the system library paths. You could also try to set the LIBRARY_PATH env variable before compiling: $ LIBRARY_PATH=/somedir/ gcc ...

[kenn]

I know that linking in command line compiling. I meant a global way to override lds search path. For example sometimes I have to compile a source code from makefile or generating makefile from configure script or from CMakeLists.txt or even more complicated ones such as vala or srt. It's hard for me to modify ld search path in such cases

[faken]

When using CMake you can select the exact libraries which are used during the configuration phase (some of these entries are shown only in advanced mode). As for configure scripts from Autotools, see this answer: stackoverflow.com/questions/7561509/…. This doesn't answer your question directly, but may help you do what you want.

[Bruce K]

Thank you! teeny enhancement -- get rid of a grep or two: sed -n 's/SEARCH_DIR("=\?([^"]\+)"); */\1\n/gp'

[Daniel Santos]

@fons Funnything is that I got here looking for this answer. :) link-time or run-time path? I guess that's the question. LIBRAY_PATH (link time) vs LD_LIBRARY_PATH.

[John O'M.]

I've found on some platforms (e.g. arm with Linaro toolchain) that ldconfig doesn't actually search the same directories as the run time linker. You can get it to output its search path, and include the paths from LD_LIBRARY_PATH by enabling debugging. E.g. LD_DEBUG=libs /lib/ld-linux.so --list cat (you can use any executable, I picked cat as the first thing I could think of). Might be worth grepping for "search path". Note that if you have an /etc/ld.so.cache that matches all needed libs, you won't get to see the built-in system search path, because it won't get that far.

[nn0p]

Is gcc search path the same with these?

[rustyx]

Be careful with ldconfig -v on FreeBSD, it will permanently remove all configured directories. Use ldconfig -r instead on FreeBSD.

[Jacklynn]

I get "cannot open 2: no such file or directory". Running ld -v 2

[jww]

The question is tagged Linux, not OS X. I don't believe OS X uses GNU's ld. The Binutil folks disabled it in the build scripts. It has been disabled for years.

[pevik]

On Linux it prints directories as well, but in form of -Lpath. So @Raphaël Londeix answer is better.

[bmacnaughton]

Why does this require such an obscure method?

[pari]

This worked like a charm ! how do we add the directories on this list , linker search path ?

[coladict]

Ah, now this explains why building with local libraries is so broken in Centos. Includes path searches are /usr/local/include then /usr/include, while linker search is /usr/lib64 then /usr/local/lib64