How does rpm resolve library dependencies

dependenciesdynamic-linkinglibrariesrpm

I try to make a package of a program which is linked to such library (output from ldd):

libwx_baseu-2.8.so.0 =>
/usr/lib64/wx-2.8-wxcontainer/libwx_baseu-2.8.so.0

Pretty straightforward, right? But when I make a package of this program (with rpmbuild) and then try to install it, rpm complains about missing library (this one above):

error: Failed dependencies:

    libwx_baseu-2.8.so.0()(64bit) 
    libwx_baseu-2.8.so.0(WXU_2.8)(64bit)

My guess is, rpmbuild set the dependency for the main lib directory, i.e. /usr/lib64.

Question — how to fix this issue (ok, one would be forced install, but I would like to avoid it)? I.e. how to build rpm so the dependencies would set for the wx-2.8-wxcontainer subdirectory (for this library)?

openSUSE 11.4, if this matters.

Edit

I can install such package with –nodeps which forces installation, and after that install program works perfectly. So clearly, rpm or rpmbuild has issues, not the system itself.

Best Answer

I think this is limitation or bug in current rpm/rpmbuild versions. I reported this issue so I think in a way question is answered:

https://bugzilla.novell.com/show_bug.cgi?id=697943

You always have to install wx rpms in pairs — one with real library, the other package which simply says "the library was installed".

libwx_baseu_net-2_8-0-wxcontainer-2.8.12-3.1.x86_64
libwx_baseu_net-2_8-0-compat-lib-wxcontainer-2.8.12-3.1.x86_64

Without the second rpm, the package manager and/or dependent application would not know that the corresponding wx library is present at all.

Related Solutions

Centos – Make RPM Satisfy Dependency Requirements of Other Installed Packages

I would recommend you alter the source rpm of this file; edit the path in which the files will be installed to, so as to not create conflicts between the files you are about to install, and those provided by libpcap.so.0.9.4 (no two rpm:s may be installed which provide the same file on same path both).

Or remove from the source rpm those files which will conflict with what you have got installed, it could be: /usr/lib/libpcap.so.0 and possibly /usr/share/man/man3/pcap.3.gz. (one is a symlink and the other a man page) from your src rpm:s .spec file, and rpmbuild it.

Then you can install (not upgrade) /root/rpmbuild/RPMS/i386/libpcap-1.4.0-1.i386.rpm along side with libpcap-0.9.4 so that the versions may peacefully coexist on your system.

If you are using yum, then you may need to edit your /etc/yum.conf to add libpcap to your list of installonlypkgs, so that yum will not replace your older version of libpcap with the one you just created (man 5 yum.conf). (if you use yum instead of plain rpm, then it can keep track of all the transactions for you with yum history. It is very powerful). You could also change the name in the .spec file in the source rpm to something like libpcap14, that's what I usually do.

Then add the path on where you installed the packages to $LD_LIBRARY_PATH, in the script/command which fires up your program and it should work. (or LD_PRELOAD your newer version of libpcap instead).

You could do what slm suggested too, it is by far the quickest way to goal: rpm2cpio /root/rpmbuild/RPMS/i386/libpcap-1.4.0-1.i386.rpm > libpcap-1.4.0-1.i386.cpio and then in a separate folder you extract the archive and use the files as described above. However, rpm is the way CentOS ships programs and I think it messy and hard to maintain in the long run.

Another cause of action can be for you to re-build all that depends on libpcap v0.9.4 to v1.0.0 and upgrade those. Normally, it would imply problems for future updates, but as you appear to be using CentOS 5, you need not worry since it is EOL.

A final option for you to consider is yum remove libpcap, see how many packages it wants to remove (yum won't actually remove anything until you hit the Y button and press enter), since you may be able to remove these packages and use yum, if it turns out you couldn't after all, you can roll back with yum history undo command (I don't remember in what version of yum this was implemented in yum, so check first if this sub command is available to you). Also, make sure that you got your repositories pointing to the repos which has these files available.

Centos 7, I thought “yum install ___” was supposed to get all the dependencies, too

Commentary on YUM & deps

YUM does do this. But it's only as good as the RPM specifies. In this case your RPM states that it'll work with any GLIBC > 2.13 but it clearly was built with a specific version of GLIBC, and will only work if the appropriate GCC symbols are available on the system:

$ rpm -qpR trillian-6.1.0.5-1.fc25.x86_64.rpm
atkmm >= 2.22.0
cairo >= 1.12.0
cairomm >= 1.10.0
gdk-pixbuf2 >= 2.26.0
glib2 >= 2.30.0
glibc >= 2.13
glibmm24 >= 2.32.0
gtk3 >= 3.4.0
gtkmm30 >= 3.4.0
libX11 >= 1.5.0
libXScrnSaver >= 1.2.0
libnotify >= 0.7.5
librsvg2-tools >= 2.36.0
libsigc++20 >= 2.2.10
libzip >= 0.10.0
openssl-libs >= 1:1.0.1
pango >= 1.30.0
pangomm >= 2.28.0
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
zlib >= 1.2.0

You can use rpm -qpR <rpm> to determine what dependencies it requires.

More on your issue

The heart of your issue is you're attempting to use a package that was built using a different version of the GCC compiler vs. what run time libraries are actually available on your OS.

In your case you're on CentOS 7.x and you really cannot mix RPMs across Fedora & CentOS like this, or at least you shouldn't.

If you look at what package owns that shared library:

$ rpm -qf /lib64/libstdc++.so.6
libstdc++-4.8.5-28.el7_5.1.x86_64

You can also investigate the shared library itself to see what GCC symbols it supports:

$ nm -D /lib64/libstdc++.so.6 | grep -i GLIBC | head -5
0000000000000000 A GLIBCXX_3.4
0000000000000000 A GLIBCXX_3.4.1
0000000000000000 A GLIBCXX_3.4.10
0000000000000000 A GLIBCXX_3.4.11
0000000000000000 A GLIBCXX_3.4.12

And finally look to see if it includes the ones that this RPM's binaries is looking for:

$ nm -D /lib64/libstdc++.so.6 | grep -iE '3\.4\.20|3\.4\.21'
$

No surprises here, this .so library doesn't include the symbols for either of those versions of GCC, hence the error.

What to do?

The typical ways you deal with this are either:

Get a binary built against your GCC's symbol definitions
Get just the libstdc++.so.6 library from some other tool (many apps opt to include libraries for easier deployment/setup/installation) and point to it via your LD_LIBRARY_PATH. You typically do it like this:
```
$ LD_LIBRARY_PATH=/path/to/lib trillian
```
Run the app in a VM
Run the app in a Docker container
Get a version of the RPM that has binaries that were built using symbols that are consistent with your OS's GCC setup.

Given the similarities between Fedora & CentOS I've had good success with many of the above. You could try #5, and try one of the older Fedora RPMs on their website to see if it was built with CentOS's version of GCC symbols.