Linux runtime not loaded on dynamic library workaround

1. Connect and run-time library file search path to Settings

library files are used when connecting (static libraries and shared libraries) and running (limited to programs that use shared libraries), and their search paths are set in the system. The general Linux system/lib and/usr/lib two directories as the default library search path, so using the libraries in these two directories does not need to set the search path can be used directly. For libraries that are outside the default library search path, you need to add the location of the library to the search path of the library. There are two ways to set the search path for a library file, which can be used as one of the following:

(1). Add a search path to the library in the/etc/ld.so.conf file. (or create a new. conf file under/ETC/LD.SO.CONF.D, add the search path one line at a-junziyang)

It is wise to add your own path to the library file into the/etc/ld.so.conf, and it is also extremely simple to include the absolute path of the library file directly into it, one at a line. For example:

/usr/x11r6/lib

/usr/local/lib

/opt/lib

It is important to note that the way the search path is set up is sufficient for the location of the library (including shared libraries and static libraries) when the program is connected, but it is not enough for programs that use shared libraries. This is because in order to speed up the location of shared libraries during program execution, and to avoid the inefficient use of search paths to find shared libraries, it is straightforward to read the library list file/etc/ld.so.cache from which to search. /etc/ld.so.cache is a non-text data file that cannot be edited directly, it is based on the search path set in/etc/ld.so.conf by/sbin/ldconfig command to set the shared library files under these search paths together (the Ldconfig command is executed with root permission).

Therefore, in order to ensure the location of the library when the program executes, after setting the library search path in/etc/ld.so.conf, you must also run the/sbin/ldconfig command to update the/etc/ld.so.cache file . Ldconfig, simply put, it is the role of the/etc/ld.so.conf listed in the path of the library file cache to/etc/ld.so.cache for use. So when you have installed some library files, (for example, just installed glib), or modified ld.so.conf to add a new library path, you need to run the/sbin/ldconfig so that all library files are cached to Ld.so.cache, if not, even if the library file is clearly Usr/lib under, also will not be used, the results of the compilation process in the wrong, missing XXX library, to see the found clearly in that put, make want to scold computer stupid pig A.

When a program is connected, the search Paths for library files (static libraries and shared libraries) can be explicitly specified with the-l parameter in addition to the settings above. Because the path set with-L is prioritized, the path to the library to which you want to connect is typically specified in this way when you connect.

This setup requires root permissions to change the/etc/ld.so.conf file and execute the/sbin/ldconfig command. Also, when the system restarts, all GTK2-based programs will use the newly installed GTK + library at run time. Unfortunately, due to the changes in the GTK + version, this can sometimes be a compatibility issue for applications, causing some programs to run abnormally. to avoid these situations, setting up the search path for the library during the installation of GTK + and its dependent libraries will take another approach . This setting does not require root privileges and is simple to set up.

(2). Specify the search path for the library in the environment variable Ld_library_path.

How to set it up:

export ld_library_path=/opt/gtk/lib: $LD _library_path

You can use the following command to view the contents of the Ld_libray_path settings:

Echo $LD _library_path

At this point, the two settings for the library are complete.

2. How to configure the search path for a connection library when cross-compiling

Cross-compilation can not use the local (i686 machine, PC machine, research and development machine) on the machine library, but in the compilation of links to the default is to use the local library, that is,/usr/lib,/lib two directories. Therefore, when cross-compiling, there are some ways to do so when compiling links to find the necessary libraries.

First of all, you need to know: when compiling only the first document, the actual library document is used in the link. (This is my understanding, if there is a wrong place, please teach the online heroes) then, talk about how to cross-compile links to find the required library.

(1) When cross-compiling, use the-l and-I parameters to specify the path to search for non-standard library documents and header documents. For example:

ARM-LINUX-GCC Test.c-l/usr/local/arm/2.95.3/arm-linux/lib-i/usr/local/arm/2.95.3/arm-linux/include

(2) using the ld.so.conf document, add the document directory where the library is used to this document, and then use the Ldconfig command to refresh the cache.

(3) Use the following command:

export ld_library_path= $LD _library_path:/usr/local/arm/2.95.3/arm-linux-lib

see ld.so.conf documentation and Pkg_ Config_path variable "this article.

through environment variables Ld_ LIBRARY_PATH Specifies the dynamic library search path (! ）。

by setting environment variables Ld_ Library_path can also specify a dynamic library search path. When multiple dynamic library search paths are specified through the environment variable, the paths are separated by a colon ":".

ld_library_path is set to global , excessive use may affect the operation of other applications, so it is more used in debugging. (for Ld_library_path's defects and usage guidelines, refer to "Why Ld_library_path are Bad"). In general, it is recommended to use the-R or-rpath option of GCC to specify the library's lookup path at compile time, and the library's path information is stored in the executable file, and it is run directly to the path to find the library, avoiding the use of the LD_LIBRARY_PATH environment variable lookup.

(4) Use the Configure parameter of the software when cross compile. For example I compile minigui-1.3.3, using the following configuration:

#!/bin/bash

Rm-f Config.cache Config.status

./configure--build=i686-linux--host=arm-linux--target=arm-linux \

Cflags=-i/usr/local/arm/2.95.3/arm-linux/include \

Ldflags=-l/usr/local/arm/2.95.3/arm-linux/lib \

--prefix=/usr/local/arm/2.95.3/arm-linux \

--enable-lite \

--DISABLE-GALQVFB \

--disable-qvfbial \

--disable-vbfsupport \

--disable-ttfsupport \

--disable-type1support \

--DISABLE-IMEGB2312PY \

--enable-extfullgif \

--enable-extskin \

--DISABLE-VIDEOQVFB \

--disable-videoecoslcd

Here I configured the cflags and Ldflags parameters, so that I don't have to modify each of the Makefile-L and-I parameters, and no need to configure Ld_library_path or overwrite the ld.so.conf document.

Summary of dynamic library usage under Linux

1. Basic concepts of static and dynamic libraries

A static library, which is added to the execution code when the executable is connected, is physically part of the execution program, and the program that is compiled with a static library does not need to be supported by the library file, but the resulting executable file is large. Dynamic libraries, which are loaded into the executor when the executable program is started, can be shared by multiple executable programs. The program generated using dynamic library compilation is relatively small, but the runtime requires library file support, which cannot be run if the library files are not available in the machine.

2. How to use dynamic libraries

    How the program uses the shared library when connecting, it must be able to find the location of the shared library at run time. The executable program of Linux is executed by default search/lib and/usr/lib both directories , and then follow the configuration in/etc/ld.so.conf to search for absolute paths . At the same time, Linux also provides the environment variable Ld_library_path for the user to choose to use, the user can set it to find a path other than the default path , such as Find/work/lib path, you can/etc/rc.d/ Add the following statement to the script that rc.local or other systems can execute after booting: Ld_library_path =/work/lib:$ (Ld_library_path). and Ld_library_path path takes precedence over system default path Find before (refer to "Using Ld_library_path" for details).

    However, the role of Ld_library_path is global, and excessive use may affect the operation of other applications, so it is more used in debugging. (for Ld_library_path's defects and usage guidelines, refer to "Why Ld_library_path are Bad"). In general, it is recommended to use the-R or-rpath option of GCC to specify the library's lookup path at compile time, and the library's path information is stored in the executable file, and it is run directly to the path to find the library, avoiding the use of the LD_LIBRARY_PATH environment variable lookup.

3. Link-time path and run-time path for the library

Modern connectors separate the link-time path (link-time path) from the run-time path (run-time path) while processing the dynamic library, and the user can specify the path to the library through-l (or-rpath), specifying the path to the Program runtime Library, Greatly improves the flexibility of the library application. For example, when we do the embedded porting #arm-linux-gcc $ (CFLAGS) –o target–l/work/lib/zlib/-llibz-1.2.3 (Work/lib/zlib is a cross-compiled zlib library), After the target is compiled we simply copy the Zlib library to the system default path of the development Board. Or, the find path is specified by-rpath (or-R), Ld_library_path.

Linux runtime not loaded on dynamic library workaround (GO)