Dynamic Linking Issues

entz · 04-13-2014, 09:36 AM

Hello Together,

Below is a situation description concerning dynamic linking. Please read carefully.
NOTES:
1) Everything preceded by a '$' is run on the CLI.
2) Assume a generic gnu/linux system.

Code:

$ldd TEST1
	linux-vdso.so.1 (0x00007fffb1ffe000)
	libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007f6e05a85000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f6e0586f000)
	librpmbuild.so.2 => not found
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f6e05567000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f6e05264000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f6e0504d000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f6e04c9e000)
	librpm.so.2 => not found
	librpmio.so.2 => not found
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f6e04a9a000)
	liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007f6e04874000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f6e05df0000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6e04656000)

As you can see the library files "librpm.so.2", "librpmio.so.2" and "librpmbuild.so.2" are reported as missing.

However, running "ls -l /usr/lib64 | grep rpm" shows the following files

Code:

$ ls -l ls -l /usr/lib64 | grep rpm 
-rwxr-xr-x  1 root root   152952 Dec 19 16:14 librpmbuild.so.3.2.0
-rwxr-xr-x  1 root root   321624 Dec 19 16:14 librpmio.so.3.2.0
-rwxr-xr-x  1 root root  1916184 Dec 19 16:14 librpm.so.3.2.0
** OUTPUT TRUNCATED **

Needless to say it's known that creating symlinks such as "ln -s librpm.so.3.2.0 librpm.so.2" could solve the problem.

QUESTION 1: What determines the library name suffix (i.e ".so.2", ".so.3.2.", ".so.0", ".so.1" .....etc) that is hardcoded into the ELF binary?

QUESTION 2: How can the hardcoded library name suffix be changed?

QUESTION 3: Related to Q2. How can a system be configured to link all binaries to something like "librpm.so" rather than to "librpm.so.0" or "librpm.so.2" ..etc ?

QUESTION 4: What is the purpose of these suffixes, considering that they aren't related to the version number of the originating package or application?

Thank You for your attention

Cheers

Didier Spaier · 04-13-2014, 12:25 PM

Answer 1: The version of the shared library against which the program was compiled.
Answer 2: It wouldn't make sense to change it as that would feed the linker with a wrong information
Answer 3: Usually files with short names are symlinks. For instance here (Slackware 14.0)

Code:

bash-4.2$ ls -l /usr/lib/librpm*
-rwxr-xr-x 1 root root   1001 août  15  2012 /usr/lib/librpm.la
lrwxrwxrwx 1 root root     15 déc.  23  2012 /usr/lib/librpm.so -> librpm.so.3.0.0
lrwxrwxrwx 1 root root     15 déc.  23  2012 /usr/lib/librpm.so.3 -> librpm.so.3.0.0
-rwxr-xr-x 1 root root 383252 août  15  2012 /usr/lib/librpm.so.3.0.0
-rwxr-xr-x 1 root root   1071 août  15  2012 /usr/lib/librpmbuild.la
lrwxrwxrwx 1 root root     20 déc.  23  2012 /usr/lib/librpmbuild.so -> librpmbuild.so.3.0.0
lrwxrwxrwx 1 root root     20 déc.  23  2012 /usr/lib/librpmbuild.so.3 -> librpmbuild.so.3.0.0
-rwxr-xr-x 1 root root 139408 août  15  2012 /usr/lib/librpmbuild.so.3.0.0
-rwxr-xr-x 1 root root    987 août  15  2012 /usr/lib/librpmio.la
lrwxrwxrwx 1 root root     17 déc.  23  2012 /usr/lib/librpmio.so -> librpmio.so.3.0.0
lrwxrwxrwx 1 root root     17 déc.  23  2012 /usr/lib/librpmio.so.3 -> librpmio.so.3.0.0
-rwxr-xr-x 1 root root 117000 août  15  2012 /usr/lib/librpmio.so.3.0.0
-rwxr-xr-x 1 root root   1044 août  15  2012 /usr/lib/librpmsign.la
lrwxrwxrwx 1 root root     19 déc.  23  2012 /usr/lib/librpmsign.so -> librpmsign.so.1.0.0
lrwxrwxrwx 1 root root     19 déc.  23  2012 /usr/lib/librpmsign.so.1 -> librpmsign.so.1.0.0
-rwxr-xr-x 1 root root  14508 août  15  2012 /usr/lib/librpmsign.so.1.0.0
bash-4.2$

Answer 4: the suffixes are related to the version number of the shared library.

Long story short: the version of the shared libraries shipped in your rpm package doesn't seem to match what your binary TEXT1 expects.

You *could* try to make "fake" symlinks, e.g. librpm.so.2 => librpm.so.3.2.0. Maybe it will work, maybe it won't.

entz · 04-13-2014, 02:31 PM

Hello Didier

and thanks for replying.

Quote:

Originally Posted by Didier Spaier

Answer 1: The version of the shared library against which the program was compiled.

Code:

bash-4.2$ ls -l /usr/lib/librpm*
-rwxr-xr-x 1 root root   1001 août  15  2012 /usr/lib/librpm.la
lrwxrwxrwx 1 root root     15 déc.  23  2012 /usr/lib/librpm.so -> librpm.so.3.0.0
lrwxrwxrwx 1 root root     15 déc.  23  2012 /usr/lib/librpm.so.3 -> librpm.so.3.0.0
-rwxr-xr-x 1 root root 383252 août  15  2012 /usr/lib/librpm.so.3.0.0
-rwxr-xr-x 1 root root   1071 août  15  2012 /usr/lib/librpmbuild.la
lrwxrwxrwx 1 root root     20 déc.  23  2012 /usr/lib/librpmbuild.so -> librpmbuild.so.3.0.0
lrwxrwxrwx 1 root root     20 déc.  23  2012 /usr/lib/librpmbuild.so.3 -> librpmbuild.so.3.0.0
-rwxr-xr-x 1 root root 139408 août  15  2012 /usr/lib/librpmbuild.so.3.0.0
-rwxr-xr-x 1 root root    987 août  15  2012 /usr/lib/librpmio.la
lrwxrwxrwx 1 root root     17 déc.  23  2012 /usr/lib/librpmio.so -> librpmio.so.3.0.0
lrwxrwxrwx 1 root root     17 déc.  23  2012 /usr/lib/librpmio.so.3 -> librpmio.so.3.0.0
-rwxr-xr-x 1 root root 117000 août  15  2012 /usr/lib/librpmio.so.3.0.0
-rwxr-xr-x 1 root root   1044 août  15  2012 /usr/lib/librpmsign.la
lrwxrwxrwx 1 root root     19 déc.  23  2012 /usr/lib/librpmsign.so -> librpmsign.so.1.0.0
lrwxrwxrwx 1 root root     19 déc.  23  2012 /usr/lib/librpmsign.so.1 -> librpmsign.so.1.0.0
-rwxr-xr-x 1 root root  14508 août  15  2012 /usr/lib/librpmsign.so.1.0.0
bash-4.2$

But how can this be? From the data provided above we can see that the supposed library version is "3.0.0". In reality however, rpm has a version number of 4.xx clearly not 3.0.0. In addition the library file "librpmsign.so" has a suffix number of 1.0.0. Again that doesn't seem to coincide with the rpm version number.

Could you clarify Please?

Thanks in Advance!

Didier Spaier · 04-13-2014, 03:23 PM

Quote:

Originally Posted by entz

From the data provided above we can see that the supposed library version is "3.0.0". In reality however, rpm has a version number of 4.xx clearly not 3.0.0. In addition the library file "librpmsign.so" has a suffix number of 1.0.0. Again that doesn't seem to coincide with the rpm version number.

Well, in case of Slackware 14.0 at least, the package rpm-4.10.0 that ships these libraries contains a lot of files, libraries, binaries, documentation, translation files, etc. Its version number is *not* related to those of these libraries, which are in fact a very small part of the package. In this case, 4.10.0 is just the version of the source tarball, provided by http://rpm.org/ from which the package is built. And a package can contain several libraries just bundled together, but independent from each other thus not having the same version number.

PS To add to the possible confusion there can be two levels of packaging:

Packaging by upstream, in other words the provider of the source files.
Packaging by the maintainer(s) of the distribution.

This explains why packages can have the same name but not at all the same content in two different distributions. For instance some distributions ship separately the "devel" files, but Slackware usually puts all the files of a given application in the same package. This is also one of the reasons for which it's not recommended to install a package intended for another distribution.

entz · 04-13-2014, 05:19 PM

Ok I see.

So If I understand you correctly, the library suffix "3.2.0" or "3.0.0" refers to the version number of a single library subsystem, Potentially one out of many. "1.0.0" or "1.2.0" would refer to the version number of the rpmsign subsystem.

Question 5: If this is the case, then what's the point of creating symlinks to them without the library version number?
Doesn't this create confusion since binaries would link against the symlinks and therefore ending up linking to a library with either a higher or lower version number?

Question 6: And what's the point of creating multiple symlinks to the same library file such as "libxx.so.6" and "libxx.so" linking to libxx.so.6.2.9 ?
As you can see in this batch of data:

Code:

linux-vdso.so.1 (0x00007fffb39fe000)
libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007fd67a8ba000)
libz.so.1 => /lib64/libz.so.1 (0x00007fd67a6a4000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fd67a4a0000)
librpmbuild.so.3 => /usr/lib64/librpmbuild.so.3 (0x00007fd67a27a000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fd679f72000)

this hypothetical binary is linked to "librpmbuild.so.3" (among others), but it's full subsystem version number is 3.2.0 (at least on my system). Now if the library version number is important then why link to a symlink with a truncated library version number? That doesn't make sense, does it?

Thanks Again

Didier Spaier · 04-13-2014, 05:47 PM

Answer 5 & 6. Not 100% sure about that, but requirements of the linker regarding some shared libraries version can be more or less picky (or relaxed). Some can require a specific version number, other any version beginning with some digit, or even accept any version. So they could look for instance for version 3.2.1 or for a version greater than 3.2.0 or any version whose number begins with 3, or even any version.

Having several symlinks at different levels is a mean to tell the linker what's available, I think.

entz · 04-13-2014, 06:42 PM

Hmmmm .... that makes sense.

Final Question: What do you know about RPATH, and how can I view what RPATH a given ELF executable has?

Regards

sundialsvcs · 04-13-2014, 09:20 PM

Don't forget the need to run and re-run ldconfig ...

pan64 · 04-14-2014, 12:49 AM

https://www.linuxquestions.org/quest...t-mean-576766/
http://stackoverflow.com/questions/6...nd-wl-rpath-wl