应用程序如何在运行时解析为共享库的不同版本? [英] How do applications resolve to different versions of shared libraries at run time?

问题描述

我对共享库在Linux上的工作方式不了解.我试图了解应用程序如何在Linux上运行时解析同一共享库的不同修订版本.

I'm a noob to how shared libraries work on linux. I am trying to understand how do applications resolve different revisions of the same shared library at run-time on linux.

据我了解，共享库具有三个名称"，例如

As far as I understand, a shared library has three "names", for example,

1. libmy.so.1.2(实名，即实际的obj文件)
2. libmy.so.1(SONAME，它嵌入在实际的obj文件中)
3. libmy.so(链接器名称，在链接时提供给链接器并嵌入在可执行文件中)

通过LDCONFIG安装该库时，它将创建以下符号链接

When you install the library via LDCONFIG, it will create the following symbolic links

• (2)=>(1)
• (3)=>(2)

现在可以说我用以下实名编译了同一库的另一个版本， libmy.so.2.0.根据指南，SONAME将为libmy.so.2.0

Now lets say I compile another version of the same library with the following real-name, libmy.so.2.0. The SONAME by guidelines would be libmy.so.2.0

在应用程序链接时，我将使用"-l"标志提供的链接器名称是什么.遵循指南，我阅读了( http://www.dwheeler.com /program-library/Program-Library-HOWTO/x36.htm l)，它不一定非要是libmy.so；如果是，那么如何区分这两个版本的obj文件?

At application link time what is the linker name that I would provide with the "-l" flag. Following the guidelines I read (http://www.dwheeler.com/program-library/Program-Library-HOWTO/x36.html), wouldn't it have to be libmy.so and if so, how will both versions of the obj file be distinguished ?

推荐答案

共享对象的版本控制如下:

Versioning of shared objects works as follows:

创建共享库时，您要给它一个真实名称和一个soname.这些用于安装共享库(创建共享库和指向共享库的链接).

When you create a shared object, you give it both a real name and an soname. These are used to install the shared object (which creates both the object and a link to it).

所以您可能会遇到这种情况:

So you can end up with the situation:

pax> ls -al xyz*
-rw-r--r--  1 pax paxgroup    12345 Nov 18  2009 xyz.so.1.5
lrwxrwxrwx  1 pax paxgroup        0 Nov 18  2009 xyz.so.1 -> xyz.so.1.5
lrwxrwxrwx  1 pax paxgroup        0 Nov 18  2009 xyz.so -> xyz.so.1

，其中xyz.so.1.5具有xyz.so.1的SONAME.

当链接器链接到xyz.so时，它将一直链接到xyz.so.1.5，并使用其SONAME中的xyz.so.1来存储在可执行文件中.然后，当您运行可执行文件时，它将尝试加载xyz.so.1，该指向特定的xyz.so.1.N(不一定是1.5版).

When the linker links in xyz.so, it follows the links all the way to xyz.so.1.5 and uses its SONAME of xyz.so.1 to store in the executable. Then, when you run the executable, it tries to load xyz.so.1 which will point to a specific xyz.so.1.N (not necessarily version 1.5).

因此，您可以安装xyz.so.1.6并更新xyz.so.1链接以指向它，而已经链接的可执行文件将代替它.

So you could install xyz.so.1.6 and update the xyz.so.1 link to point to it instead and already-linked executables would use that instead.

这种多层方法的一个优点是您可以拥有多个同名的可能不兼容的库(xyz.so.1.*，xyz.so.2.*)，但是，在每个主要版本中，您可以自由升级它们，因为它们应该是兼容的.

One advantage of this multi-layer method is that you can have multiple potentially incompatible libraries of the same name (xyz.so.1.*, xyz.so.2.*) but, within each major version, you can freely upgrade them since they're supposed to be compatible.

链接新的可执行文件时:

When you link new executables:

• 与xyz.so链接的链接将获得最新主要版本的最新次要版本.
• 与xyz.so.1链接的其他人将获得特定主要版本的最新次要版本.
• 仍然与xyz.so.1.2链接的其他人将获得特定主要版本的特定次要版本.

• Those linking with xyz.so will get the latest minor version of the latest major version.
• Others linking with xyz.so.1 will get the latest minor version of a specific major version.
• Still others linking with xyz.so.1.2 will get a specific minor version of a specific major version.

现在，当我们检查您的评论时，请牢记最后一段:

Now keep that last paragraph in mind as we examine your comment:

现在可以说我用以下实名libmy.so.2.0编译同一库的另一个版本.按照准则，SONAME为libmy.so.2.0.

Now lets say I compile another version of the same library with the following real-name, libmy.so.2.0. The SONAME by guidelines would be libmy.so.2.0.

不，我不这么认为. soname很有可能是libmy.so.2，以便您可以对2.x流进行较小的更新并获得最新的行为.

No, I don't believe so. The soname would be more likely to be libmy.so.2 so that you can make minor updates to the 2.x stream and get the latest behaviour.

这篇关于应用程序如何在运行时解析为共享库的不同版本?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！