Shulou(Shulou.com)06/03 Report--

This article mainly introduces "how to find the dynamic library when the program is running". In the daily operation, I believe that many people have doubts about how to find the dynamic library when the program is running. The editor consulted all kinds of data and sorted out the simple and easy-to-use operation methods. I hope it will be helpful for everyone to answer the doubt of "how to find the dynamic library when the program is running". Next, please follow the editor to study!

To a large extent, it is inevitable that dynamic libraries will be used when we develop a random CumberCraft + program:

/ / Source: official account [programming Zhuji] # include int main () {printf ("hello, programming Zhuji\ n"); return 0;}

Compile and view the dynamic libraries used:

$gcc-o main main.c $ldd main linux-vdso.so.1 (0x00007ffdf8fdf000) libc.so.6 = > / lib/x86_64-linux-gnu/libc.so.6 (0x00007f1f8535e000) / lib64/ld-linux-x86-64.so.2 (0x00007f1f85951000)

From the results of the ldd command, we can see which dynamic libraries the main program depends on and which path it is in. So have you ever thought about how to find the path to the dynamic library and what the search order is?

Prepare dynamic library

Before this, if you do not have a basic understanding of dynamic libraries, it is recommended that you read "talking about static libraries and dynamic libraries" or other related materials. To illustrate the following, let's first create a simple dynamic library. You can also refer to "hand-in-hand teaching you to make a dynamic library":

/ / test.c / / Source: official account [programming Zhuji] # include # include "test.h" # include "test1.h" void test () {printf ("I am test" Hello, programming Zhuji\ n "); test1 ();} / / test.h void test (); / / test1.c # include # include" test1.h "void test1 () {printf (" test1,needed by test\ n ");} / / test1.h void test1 ()

Make dynamic libraries libtest.so and libtest1.so respectively, which will be used in later examples:

$gcc test1.c-fPIC-shared-o libtest1.so $gcc test.c-fPIC-shared-o libtest.so-L. -ltest1

So you will see that a libtest.so and libtest1.so file are generated in the current directory, where litest.so depends on libtest.so

Note that because libtest.so depends on libtest1.so, the path to the test1 to be linked is specified with-L, so we see:

$ldd libtest.so linux-vdso.so.1 (0x00007ffd1bbca000) libtest1.so = > not found libc.so.6 = > / lib/x86_64-linux-gnu/libc.so.6 (0x00007f9f1d0ae000) / lib64/ld-linux-x86-64.so.2 (0x00007f9f1d6a1000)

You can see here that libtest relies on the libtest1 library, but notice in particular that libtest1.so points to not found. Does that have any impact? We'll see later.

Find a path when linking

As we all know, before compiling to an executable file, the linker also needs to find the path of the dynamic library to link to the dynamic library. Otherwise, how to link the specified dynamic library on it? So what is the order?

The first thing to look for is the path of the compile-time link. Modify the previous main.c to call the test function in libtest.so:

/ / Source: official account [programming Zhuji] # include # include "test.h" int main () {test (); / / call test function return 0 in libtest.so;}

Compile link:

$gcc-o main main.c-I. /-L.A. /-ltest-ltest1

It was compiled perfectly. In addition, if we move both libtest.so and libtest1.so under / usr/lib, we find that we can compile without-L:

$gcc-o main main.c-I. /-ltest-ltest1

What needs to be noted here is that we specify the path to the search base through-L./, and because libtest.so depends on libtest1.so, we also need to test1 the link when compiling the link.

Summary

As you can see from the above, when linking, we use the-L parameter to search for the library path to be linked, but this path information will not be written to the ELF file, so you will see not found through the ldd command, while you can specify the search path when linking through-rpath. This information will be written to the ELF file. The final result is that because libtest.so depends on libtest1.so, other programs rely on libtest.so. It automatically searches for other libraries it depends on from the rpath written to ELF, so you only need to link to libtest, for example:

When creating the library libtest1.so, add the-rpath-link option:

$gcc test.c-fPIC-shared-o libtest.so-L. -ltest1-Wl,-rpath-link $(pwd)

When compiling main, you do not need to specify the link libtest1.so specifically

$gcc-o main main.c-L. /-ltest

All you need to do is link libtest.so, and the libtest1.so it depends on is also linked in.

Of course, if the path specified by-L is not there, it will look somewhere else, otherwise how can the dependent system library be found? The general order of summary is as follows:

-L specifies the link path

Search the dependent search order in the dependent library with the-rpath-link or-rpath option (mentioned later)

Gcc default link path (gcc-- print-search-dir | grep libraries view)

The lookup path configured by the linker (ld-verbose | grep SEARCH_DIR view)

There may be some differences for a specific system or linker, but this is roughly the case.

Runtime lookup path

Although the previous compilation was successful, we ran it and found that the run failed.

$. / main. / main: error while loading shared libraries: libtest.so: cannot open shared object file: No such file or directory

In fact, we can also see this by using the ldd command:

Linux-vdso.so.1 (0x00007ffcd566e000) libtest.so = > not found libc.so.6 = > / lib/x86_64-linux-gnu/libc.so.6 (0x00007f356d1f6000) / lib64/ld-linux-x86-64.so.2 (0x00007f356d7e9000)

LD_PRELOAD environment variable

When this environment variable is introduced in "performance Optimization-using an efficient memory allocator," it is also mentioned that it is very convenient for testing, and again, this approach is best used only for testing, because it has a very high priority and affects the overall situation. It is also easy to use:

$export LD_PRELOAD=./libtest.so $. / main

To avoid affecting subsequent validation, unset the environment variable here:

Unset LD_PREALOD

Find rpath path

In the above case, the dynamic library cannot be found, so it will first go to rpath to specify the path to find it, which needs to be specified at compile time:

$gcc test.c-fPIC-shared-o libtest.so-L. -ltest1-Wl,-rpath $(pwd) $gcc-o main main.c-L. -ltest-Wl,-rpath $(pwd) $. / main I am test;hello, programming Zhuji test1,needed by test

That is, if we specify a path at compile time, we can find it, but this information is written to the ELF file.

LD_LIBRARY_PATH environment variable

You can also use this environment variable to set the path to search the base.

$gcc-o main main.c-L. -ltest $export LD_LIBRARY_PATH=./ $. / main

There is no problem with running in this way.

Similarly, to avoid affecting later tests, unset the environment variable:

Unset LD_LIBRARY_PATH

Path in / etc/ld.so.conf

The contents of this file on my machine are as follows:

$cat / etc/ld.so.conf include / etc/ld.so.conf.d/*.conf $ls / etc/ld.so.conf.d/ fakeroot-x86_64-linux-gnu.conf libc.conf x86_64-linux-gnu.conf

So what it really means is that all conf paths under the / etc/ld.so.conf.d/ directory contain paths. Open one of the libc.conf, which contains the following paths:

$/ usr/local/lib

In that case, let's copy the previous libtest.so to this directory (sudo permission may be required):

$sudo cp libtest.so / usr/local/lib $sudo ldconfig $. / main I am test;hello, programming Zhuji test1,needed by test

Note that after the copy is completed here, you need to execute ldconfig, which updates the corresponding shared library so that the executable can find it. In fact, after the execution is complete, you can actually find it in the / etc/ld.so.cache file:

$grep-a libtest.so / etc/ld.so.cache

Similarly, in order to affect later tests, remember to delete:

Rm / usr/local/lib/libtest.so

In fact, this is to look first from the path in / etc/ld.so.cache and then from the path in ld.so.conf. We can see it later by order.

/ usr/lib,/lib/

Of course, if none of the above paths exist, we will eventually look for them under lib or / usr/lib. To verify, we copy the library to the / lib directory.

$cp libtest.so / lib $. / main I am test;hello, programming Zhuji test1,needed by test

It also works normally.

Summary

To summarize, the search order of the dynamic library is as follows:

The LD_PRELOAD environment variable specifies the library path

-specify a path when rpath links

LD_LIBRARY_PATH environment variable setting path

/ etc/ld.so.conf configuration file specifies the path

Default shared library path, / usr/lib,lib

You can easily verify the priority of the above search paths. The simple way is to place libraries with different functions of the same name in these locations to see which path it uses first, and you can try it yourself.

LD_DEBUG

This environment is usually used for debugging. For example, view the entire mount process:

$LD_DEBUG=files. / main

Or look at the process of finding dependent libraries:

$LD_DEBUG=libs. / main 3557: find library=libtest.so [0]; searching 3557: search cache=/etc/ld.so.cache 3557: trying file=/usr/local/lib/libtest.so

You can also display the process of finding symbols:

LD_DEBUG=symbols. / main at this point, the study on "how to find the dynamic library when the program is running" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.