How to solve the dependency problem?

Whether it is a beginner in the Linux arena or an expert with many years of experience, package dependencies may be more or less encountered during installation or compilation of software packages, resulting in the installation process being unable to continue, for example, when the Administrator installs LAMP, the package must be libgd. so file, which belongs to the GD software package. However, when installing the GD software package, it may be dependent on other software packages, and other software packages need to be installed. At this time, some administrators lose patience. How can I solve the dependency problem of such Linux software packages? Before talking about this specific measure, let's talk about the software dependency in Linux.

1. What is dependency?

Programs depend on the shared libraries of program code so that they can send system calls to send output to devices or open files (Shared inventory is in many aspects, not limited to system calls ). There is no shared library. Every time a programmer develops a new program, Each programmer needs to rewrite these basic system operations from the beginning. When compiling a program, the programmer links his code to these libraries. If the link is static, the compiled shared library object code is added to the program execution file. If the link is dynamic, the compiled shared library object code is only required to be loaded by the programmer at runtime. Dynamic executable files depend on the correct shared library or shared object for operations. Rpm dependency tries to forcibly implement the shared object requirement of dynamic executable files during installation so that no problems related to the dynamic link process will occur when the program runs in the future.

Note: there is also a type of dependency, which is based on explicit entries. rpm forces this dependency to the rpm configuration file through programmers, but we do not care about this type of dependency currently, this dependency is easy to solve. Here we will focus on more complex shared object dependencies enforced by rpm.

Ii. Dynamic executable files and shared objects

Dynamic executable files use the shared object names of library files used for initial compilation and linking to programs to find shared objects. They are searched in a few standard locations, such as in the/lib and/usr/lib directories and in the LD_LIBRARY_PATH environment variables (mainly used to specify the search for shared libraries, for example, when installing Oracle, specify the path export LD_LIBRARY_PATH = $ ORACLE_HOME/lib:/usr/local/lib) in the specified directory. By the way, shared objects found in these library directories may not be real files; they may be symbolic links to real library files located elsewhere (but they are still in a directory of the standard library directory ). At least from the perspective of the system administrator, there is usually no relationship between the name of the shared library package used to create the shared library file and the name of the shared library file. For example, the GLIBC 2.3 Package is used to create a libc. so.6 shared library file. It is also noted from this example that the version number (. 6) added to the end of the shared library file name does not matter with the version number (2.3) used to create it. This was intentionally completed by the shared library software package developer so that the new version of GLIBC can reuse the same shared library file name libc. so.6. This allows you to load a new version of GLIBC on the system without interrupting the dynamic link to lib. so.6 all programs that share the library file, of course, assume that the new version of GLIBC is backward compatible with the old version GLIBC that is initially linked to the dynamic executable file. Therefore, even if library files or shared object files have version numbers related to them, these versions cannot help you determine which version of the shared software package they come from.

Note: When the whatprovides option is used for the rpm query command, you can obtain information about the existing shared objects loaded to the system using the rpm package. This confusion is caused by the fact that a single shared library file may support shared library software packages of a certain range. For example, to check the GLIBC shared library Package supported by the soname library file/lib/libc. so.6, run the following command:

# Objdump -- all-headers/lib/libc. so.6 | less

Scroll down this report until Version definitions: part is reached to view which GLIBC versions are supported by the libc. so.6 shared library file:

Version definitions:

1 0x01 0x0865f4e6 libc. so.6

2 0x00 0x0d696910 GLIBC_2.0

3 0x00 0x0d696911 GLIBC_2.1

GLIBC_2.0

4 0x00 0x09691f71 GLIBC_2.1.1

GLIBC_2.1

5 0x00 0x09691f72 GLIBC_2.1.2

GLIBC_2.1.1

6 0x00 0x09691f73 GLIBC_2.1.3

GLIBC_2.1.2

7 0x00 0x0d696912 GLIBC_2.2

GLIBC_2.1.3

8 0x00 0x09691a71 GLIBC_2.2.1

GLIBC_2.2

9 0x00 0x09691a72 GLIBC_2.2.2

GLIBC_2.2.1

10 0x00 0x09691a73 GLIBC_2.2.3

GLIBC_2.2.2

11 0x00 0x09691a74 GLIBC_2.2.4

GLIBC_2.2.3

12 0x00 0x09691a76 GLIBC_2.2.6

GLIBC_2.2.4

13 0x00 0x0d696913 GLIBC_2.3

GLIBC_2.2.6

14 0x00 0x09691972 GLIBC_2.3.2

GLIBC_2.3

15 0x00 0x09691973 GLIBC_2.3.3

GLIBC_2.3.2

16 0x00 0x09691974 GLIBC_2.3.4

GLIBC_2.3.3

17 0x00 0x0d696914 GLIBC_2.4

GLIBC_2.3.4

18 0x00 0x0d696915 GLIBC_2.5

GLIBC_2.4

19 0x00 0x0963cf85 GLIBC_PRIVATE

GLIBC_2.5

20 0x00 0x0b792650 GCC_3.0

In this example, the 1ibc. so.6 shared library file supports all the dynamic execution files originally developed for GLIBC versions 2.0 to 2.5. Note: You can also use the objdump command to extract the soname from the shared library file. The command is as follows:

# Objdump -- all-headers/lib/libcrypto. so.0.9.8b | grep SONAME

SONAME libcrypto. so.6

Objdump:/lib/libcrypto. so.0.9.8b: no recognized debugging information

Next, we will discuss how the rpm software package is generated so that these library dependencies are known when you install the rpm software package on a new system.
Iii. Rpm software package and shared library dependency

When a programmer generates an rpm package, The ldd command is used to report all the shared libraries used by all the dynamic executable files in the dynamic Executable File package. Another chaos is caused by the fact that different dynamic executable files in the same software package may be linked to different versions of the same shared library software package. For example, different programs in the Heartbeat software package may have been developed and dynamically linked to different GLIBC versions of libc. so.6 sonmae shared library files. Run the-q and -- requires parameters on the rpm command to view the complete list of shared libraries required by the rpm software package. For example, to see all the required dependencies of the Heartbeat rpm package, run the following command:

# Rpm-q -- requires-p heartbeat-1.x.x.i386.rpm

This generates the following report:

Sysklogd

/Bin/sh

/Bin/sh

/Usr/bin/python

Ld-linux.so.2

Libapphb. so.0

Libc. so.6

Libc. so.6 (GLIBC_2.0)

Libc. so.6 (GLIBC_2.1)

Libc. so.6 (GLIBC_2.1.3)

Libc. so.6 (GLIBC_2.2)

Libc. so.6 (GLIBC_2.3)

Libccmclient. so.0

Libdl. so.2

Libglib-1.2.so.0

Libhbclient. so.0

Libpils. so.0

Libplumb. so.0

Libpthread. so.0

Librt. so.1

Libstonith. so.0

Note that in this report, libc. so.6 soname is required. This shared library must support dynamic executable files linked using GLIBC Shared Software Package versions 2.0, 2.1, 2.1.3, 2.2, and 2.3. This is determined by the following fact: different dynamic executable files in the Heartbeat software package are linked to each version of the libc. so.6 library of different versions. After learning how dynamic executable files, shared objects, soname, and shared library software packages are related to each other, let's take a look at the following example: When you try to install the rpm software package, and what will happen when it fails due to dependency errors. Yum can automatically download and install the RPM package from the specified server. It can automatically process dependencies and install all dependent software packages at a time without the need for tedious download and installation.

4. Manually solve dependency problems

Generally, when you try to install a software package that is not included in the release (and a software package that cannot be automatically resolved by an update tool like up2date, apt-get, or Yum, the rpm dependency error occurs. For example, if you try to use the rpm-ivh * rpm command on the old Linux release, for example, all Heartbeat rpm packages, you may encounter the following error during installation:

Error: failed dependencies:

Libc. so.6 (GLIBC_2.3) is needed by heartbeat-1.x.x

Libc. so.6 (GLIBC_2.3) is needed by heartbeat-pils-1.x.x

Libcrypto. so.0.9.6 is needed by heartbeat-stonith-1.x.x

Libsnmp-0.4.2.6.so is needed by heartbeat-stonith-1.x.x

Note that the rpm command does not interfere with the version number of each GLIBC shared library package required for reporting-it only reports the version number (GLIBC_2.3) of the highest number required ). (Assuming that the original software package developer will not link the executable files in the same software package to the shared library software package of incompatible versions) all these faults report the required shared library name or soname (instead of the file name, soname always starts with "lib ). However, you can delete the soname ending version number added to the rpm report and quickly check whether the shared libraries are installed using the locate command in the system (assuming that your locate database is the latest, for more information, see the locate or slocate manual page ). For example, to find the libcrypto file, enter:

# Locate libcrypto

[Root @ localhost ~] # Locate libcrypto

/Lib/libcrypto. so.0.9.8b

/Lib/libcrypto. so.6

/Root/. Trash/vmware-tools-distrib/lib/lib32/libcrypto. so.0.9.8

/Root/. Trash/vmware-tools-distrib/lib/lib32/libcrypto. so.0.9.8/libcrypto. so.0.9.8

/Root/. Trash/vmware-tools-distrib/lib/lib64/libcrypto. so.0.9.8

/Root/. Trash/vmware-tools-distrib/lib/lib64/libcrypto. so.0.9.8/libcrypto. so.0.9.8

/Usr/lib/libcrypto.

/Usr/lib/libcrypto. so

/Usr/lib/pkgconfig/libcrypto. pc

/Usr/lib/vmware-tools/lib32/libcrypto. so.0.9.8

/Usr/lib/vmware-tools/lib32/libcrypto. so.0.9.8/libcrypto. so.0.9.8

/Usr/lib/vmware-tools/lib64/libcrypto. so.0.9.8

/Usr/lib/vmware-tools/lib64/libcrypto. so.0.9.8/libcrypto. so.0.9.8

If this command does not find a libcrypto shared library file on the system, you will need to go to the Internet and find out which shared library package contains the shared library file. One quick and easy way to do this is to enter the name of the shared library in the search bar on the http://rpmfind.net. If you enter the text libcrypto. so in this search, you will soon know that this shared library is provided by the openssl software package.



If the old version of the shared library package has been installed on the system, run the following command to confirm that the software contains the shared library file you need:

# Rpm-q -- provides openssl

[Root @ localhost ~] # Rpm-q -- provides openssl

Config (openssl) = 0.9.8b-10. el5

Lib4758cca. so

Libaep. so

Libatalla. so

Libchil. so

Libcrypto. so.6

Libcswift. so

Libgmp. so

Libnuron. so

Libssl. so.6

Libsureware. so

Libubsec. so

Openssl = 0.9.8b-10. el5

This command reports all the content provided in this rpm package (this includes the soname of the shared library file provided by the package ). Note: As mentioned above, the shared library software package version does not have any correspondence with the shared library file (soname) version number. This is not discussed here, because the soname symbolic link may point to shared library files of different versions, this is done when you try to avoid interrupting the existing dynamic executable files when installing the new version of the shared software package.
V. Automatic resolution of dependency faults

When you use the rpm software package to generate, upgrade, or add new features to the system, dependency failure may quickly become a nightmare. You can avoid this nightmare by upgrading services or tools from your release supplier. For example, when you select the rpm package to be installed, the Red Hat tool up2date automatically downloads and installs all rpm Dependencies from Red Hat. The following lists several free community-based methods to accomplish the same thing: http://www.rpm.org /. Below we will see only one of these automatic update tools: Yum.

1. Use Yum to install the rpm package

The Yum (Yellow dog Updater, Modified) program can be downloaded from: http://yum.baseurl.org/download/3.4/yum-3.4.3.tar.gz

After downloading this software package, you can use the following command to install it like any other rpm software package:

# Rpm-ivh yum *

You may need to update the repository for downloading your rpm software package. The list of available Yum repositories for Fedora is to be switched to a different repository in the http://www.fedoratracker.org, download a file from these files, and install the file as A/etc/yum. conf file. Now you can use the following command to tell Yum to report all software packages stored in the Yum Repository:

# Yum list

[Root @ localhost ~] # Yum list | more

This system is not registered with RHN.

RHN support will be disabled.

Loading "security" plugin

Loading "rhnplugin" plugin

Installed Packages

Deployment_Guide-en-US.noarch 5.2-9 installed

Deployment_Guide-zh-CN.noarch 5.2-9 installed

Deployment_Guide-zh-TW.noarch 5.2-9 installed

GConf2.i386 2.14.0-9. el5 installed

GConf2-devel.i386 2.14.0-9. el5 installed

ImageMagick. i386 6.2.8.0-4. el5_1.1 installed

MAKEDEV. i386 3.23-1.2 installed

MySQL-python.i386 1.2.1-1 installed

NetworkManager. i386 1:0. 6.4-8. el5 installed

NetworkManager-glib.i386 1:0. 6.4-8. el5 installed

2. Use Yum to install the new rpm package

In this example, a new GLIBC package is installed. Install the latest GLIBC and all its Dependencies with simple commands:

# Yum update glibc

If everything works, the Yum program will automatically detect, download, and install all the rpm packages required by the latest GLIBC package (here the GLIBC package is built for your release, not necessarily the latest version of GLIBC software package available (use the version number of the GLIBC shared library software package approved by the release or install the GLIBC software package version of the dynamic executable file not required for normal system operations). You can also use the list parameter in the Yum and grep commands to find the software package to be installed. For example, to find a software package with SNMP in its name, enter:

# Yum list | grep snmp

This command returns the following report:

This system is not registered with RHN.

RHN support will be disabled.

Net-snmp.i386. 3.1-24. el5 installed

Net-snmp-libs.i386. 3.1-24. el5 installed

Net-snmp-perl.i386. 3.1-24. el5 installed

Net-snmp-utils.i386. 3.1-24. el5 installed

It is now easy to use YUM to download and install all these rpm packages.

6. Suggestions for upgrading Gilbc

Glibc library is the underlying Runtime Library of Linux, and its performance is of great significance for the operation of the entire system. The Glibc library contains a large number of functions. The functions can be roughly divided into two types. One is the system calling interfaces that communicate with the core of the operating system. They are called as function functions, provides packaging and preprocessing for Linux operating system calls. The other class is a general function object, which provides the implementation of frequently-used functions and is used as a tool-type function. In practice, there are a lot of software that can be installed and run only by relying on the Glibc version. To put it bluntly, the Glibc version requires a higher version. The applications in these compiling environments must have the same running environment as other programs. I often encounter an administrator installing the latest Linux release version for the server in production, as a result, the application software cannot be installed because the Glibc version is incorrect. Some of them are written on the original release version glibc, and some are upgraded or downgraded. As a result, the entire system crashes, you only need to select the corresponding glibc in the corresponding Linux release version. For example, if one of our application software is developed under rhel3.0, you need the corresponding release version, it is hard to say anything else. It is impossible to upgrade or downgrade Glibc to adapt to the application software. The final solution to the problem is to find RHEL3 and install it. In table 1, I will list several original Glibc versions of linux distributions for your reference.
Click an image to view the large image



Glibc library and core functional components

I. Notes:

GCC depends on glibc

Binutils depends on glibc (binutils provides a series of tool programs used to create, manage, and maintain binary target files, such as assembly (as), connection (ld), static library archiving (ar), disassembly)

Make depends on glibc

Header files are required by gcc during compilation, but they are all text files, so there is no running environment.

Commonly used tools depend on glibc and various dynamic libraries.

The following table lists Glibc of multiple important Linux distributions.

Glibc for Linux release

Redhat 9 glibc-2.3.2-5

Fedora 1 glibc-2.3.2

Redhat Enterprise Linux As 3 glibc-2.3.2-95

Redhat Enterprise Linux As 4 glibc-2.3.4

Red hat Enterprise linux 5 glibc-2.5-24

Red hat Enterprise linux 6 glibc-2.9

Centos 5.x glibc-2.5

Suse Linux Enterprise Server 9 glibc-2.3.2-92

Suse Linux enterprise Server 10 glibc-2.4.31.54

Suse Linux Enterprise Server 11 glibc-2.9

Click an image to view the large image



Glibc (32) bit for Linux release

The following describes how to query the glibc version number:

# Ls-al/lib/libc *

Or use the following command to implement

# Rpm-qp | grep glibc

Debian-based systems can also be found through dpkg-l | grep libc6. In short, information about glibc can be seen in the/usr/share/doc directory.

VII. Summary

In most cases, when the software package dependency problem occurs, the file name provided by the operating system is directly related to the software package name. It is possible that the file name is the package name. However, sometimes the file name is different from the package name. At this time, most system administrators may not be able to find the corresponding software package by file name. In this case, you can first find the best options in the system installation CD. If you find the best options at that time, you need to query the software package name using the professional websites I mentioned above. After a system administrator installs a software package, if there is a dependency between the software packages, it is best to take the book or record it by other means. So that it can be convenient and practical next time. Pay attention to the accumulation in the work. I believe that most of the software package dependency problems will be solved.

This article from the "Li chenguang Original Technology blog" blog, please be sure to keep this source http://chenguang.blog.51cto.com/350944/1034095