CODEWITHSUNDEEP
linuxbashrpmqpid
Sam Gomari
Sam Gomari

Reputation: 765

Check the version of used libraries in an rpm package

I installed qpid on RHEL 7, and wanted to know if it's picking up the right version of boost. How do you use rpm command to check if it's using the right set of libs. It doesn't have to be rpm command , i just would like to know if using the right version of boost.

Upvotes: 1

Views: 6000

Answers (4)

Thomas Dickey
Thomas Dickey

Reputation: 54583

For a given package, you can use rpm -qR to show its dependencies, and then for each dependency, rpm -q --whatprovides to show the actual package names. I do this in my build-logs, to keep track of what I built, using a script to format the listing from rpm for readability.

For example, given an installed "ncurses6", and the script starts by doing this:

rpm -qR ncurses6

I get output like this:

/bin/sh
/usr/bin/pkg-config
libc.so.6()(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libformw6.so.6()(64bit)
libformw6.so.6(NCURSESW6_5.1.20000708)(64bit)
libgcc_s.so.1()(64bit)
libgcc_s.so.1(GCC_3.0)(64bit)
libm.so.6()(64bit)
libmenuw6.so.6()(64bit)
libmenuw6.so.6(NCURSESW6_5.1.20000708)(64bit)
libncurses++w6.so.6()(64bit)
libncursesw6.so.6()(64bit)
libncursesw6.so.6(NCURSESW6_5.1.20000708)(64bit)
libncursesw6.so.6(NCURSESW6_5.3.20021019)(64bit)
libncursesw6.so.6(NCURSESW6_5.4.20040208)(64bit)
libncursesw6.so.6(NCURSESW6_5.5.20051010)(64bit)
libncursesw6.so.6(NCURSESW6_5.6.20061217)(64bit)
libncursesw6.so.6(NCURSESW6_5.7.20081102)(64bit)

and my script produces a report like this:

** package/ncurses.spec
** ncurses6
package bash-4.3.42-3.fc23.x86_64
        /bin/sh
package glibc-2.22-16.fc23.x86_64
        libc.so.6()(64bit)
        libc.so.6(GLIBC_2.14)(64bit)
        libc.so.6(GLIBC_2.2.5)(64bit)
        libc.so.6(GLIBC_2.3)(64bit)
        libc.so.6(GLIBC_2.3.4)(64bit)
        libc.so.6(GLIBC_2.4)(64bit)
        libm.so.6()(64bit)
        libutil.so.1()(64bit)
        rtld(GNU_HASH)
package libgcc-5.3.1-6.fc23.x86_64
        libgcc_s.so.1()(64bit)
        libgcc_s.so.1(GCC_3.0)(64bit)
package libstdc++-5.3.1-6.fc23.x86_64
        libstdc++.so.6()(64bit)
        libstdc++.so.6(CXXABI_1.3)(64bit)
        libstdc++.so.6(GLIBCXX_3.4)(64bit)
package ncurses6-6.0-20160528.x86_64
        libformw6.so.6()(64bit)
        libformw6.so.6(NCURSESW6_5.1.20000708)(64bit)
        libmenuw6.so.6()(64bit)
        libmenuw6.so.6(NCURSESW6_5.1.20000708)(64bit)
        libncurses++w6.so.6()(64bit)
        libncursesw6.so.6()(64bit)
        libncursesw6.so.6(NCURSESW6_5.1.20000708)(64bit)
        libncursesw6.so.6(NCURSESW6_5.3.20021019)(64bit)
        libncursesw6.so.6(NCURSESW6_5.4.20040208)(64bit)
        libncursesw6.so.6(NCURSESW6_5.5.20051010)(64bit)
        libncursesw6.so.6(NCURSESW6_5.6.20061217)(64bit)
        libncursesw6.so.6(NCURSESW6_5.7.20081102)(64bit)
        libncursesw6.so.6(NCURSESW6_5.8.20110226)(64bit)

(the script is 200 lines of Perl, counting comments and whitespace: a good student exercise).

Upvotes: 1

John Bollinger
John Bollinger

Reputation: 181179

This is not usually a problem you need to deal with for software installed via RPMs, as long as you avoid overriding rpm / yum / dnf's dependency checking. The RPM will specify library dependencies down to library SONAME, and package installation / upgrade / removal verifies that those library dependencies are satisfied and remain satisfied.

However, in the event that you have bad packages somewhere in the mix, or if you install any unpackaged software, or if you use --force to override dependency checks, then it's possible to have library issues with rpm-packaged software, not to mention other software. There could be multiple libraries installed with the same SONAME, and the dynamic linker could choose a different one of them than you want it to do. Or you might have unsatisfied library dependencies.

You may therefore want to determine exactly which libraries will be dynamically linked to a given executable, independent of packaging. You can do this via the ldd command. For example, on my CentOS 6 system:

$ ldd /bin/rpm
    linux-vdso.so.1 =>  (0x00007ffdabd77000)
    librpmbuild.so.1 => /usr/lib64/librpmbuild.so.1 (0x0000003708600000)
    librpm.so.1 => /usr/lib64/librpm.so.1 (0x0000003709200000)
    libmagic.so.1 => /usr/lib64/libmagic.so.1 (0x0000003707a00000)
    librpmio.so.1 => /usr/lib64/librpmio.so.1 (0x0000003709600000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003707e00000)

[...]

    libnspr4.so => /lib64/libnspr4.so (0x0000003716200000)

This is also useful for detecting library dependencies that are not satisfied at all; again, this is rarely a problem with RPM-packaged software, but I run into it from time to time with pre-built software distributed in other kinds of packaging.

Upvotes: 0

K.Boyette
K.Boyette

Reputation: 343

Maybe this will help.

rpm -qa will list all the installed programs.

If you know the boost version you should be using, then you can use rpm -qa | grep <program_name>.

rpm -qi <package_name> can give you more specific information about the package version. The -qi flag gives you version, release, install date, size, etc.

Upvotes: 1

Mureinik
Mureinik

Reputation: 312086

You could use rpm -qa to check the installed RPMs, and examine the results. E.g., from my machine (Fedora 23, but the same principal should work for RHELs):

mureinik@computer ~$ rpm -qa | grep boost
ibus-typing-booster-1.4.5-1.fc23.noarch
boost-thread-1.58.0-11.fc23.x86_64
boost-date-time-1.58.0-11.fc23.x86_64
boost-iostreams-1.58.0-11.fc23.x86_64
boost-system-1.58.0-11.fc23.x86_64

Upvotes: 2

Related Questions