# Bug in Rocky's systemtap-runtime-4.4-11 package? **URL:** \ **Category:** Rocky Linux Help & Support\ **Created:** [September 11, 2021, 7:25pm UTC](https://forums.rockylinux.org/t/bug-in-rockys-systemtap-runtime-4-4-11-package/4034 "2021-09-11T19:25:28Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![jsalk](https://avatars.discourse-cdn.com/v4/letter/j/b5ac83/32.png) [@jsalk](https://forums.rockylinux.org/u/jsalk)\ **Post date:** [September 11, 2021, 7:25pm UTC](https://forums.rockylinux.org/t/bug-in-rockys-systemtap-runtime-4-4-11-package/4034/1 "2021-09-11T19:25:28Z")
Hi, this is my very first post here, so please direct me to a somewhere else if this is the wrong place to ask. I did run a (mostly) successful CentOS 8.4 to Rocky 8.4 conversion by using the migrate2rocky.sh script with some minor unrelated tweaks. However, some additional packages were installed in the migration process to resolve recursive dependencies that were not necessary in CentOS 8.4. I’ve looked into this and one of the reasons seems to be that the package systemtap-runtime-4.4-11.el8\_4.x86\_64 has different library version dependencies in CentOS 8.4 and Rocky 8.4. This is an excerpt from ‘yum deplist systemtap-runtime-4.4-11.el8\_4.x86\_64’ command on CentOS 8.4: ```auto [...] dependency: libdyninstAPI.so.10.2()(64bit) provider: dyninst-10.2.1-2.el8.x86_64 provider: gcc-toolset-10-dyninst-10.2.1-2.el8.x86_64 [...] dependency: libsymtabAPI.so.10.2()(64bit) provider: dyninst-10.2.1-2.el8.x86_64 provider: gcc-toolset-10-dyninst-10.2.1-2.el8.x86_64 [...] ``` And this is an excerpt from the very same command in Rocky 8.4: ```auto [...] dependency: libdyninstAPI.so.10.1()(64bit) provider: gcc-toolset-9-dyninst-10.1.0-1.el8.x86_64 [...] dependency: libsymtabAPI.so.10.1()(64bit) provider: gcc-toolset-9-dyninst-10.1.0-1.el8.x86_64 [...] ``` Also note that in CentOS 8.4 there are two providers of libdyninstAPI.so.10.2: dyninst-10.2.1-2.el8.x86\_64 and gcc-toolset-10-dyninst-10.2.1-2.el8.x86\_64, with the former being installed in my original CentOS 8.4 system. Whereas, in Rocky 8.4, there is only _one_ provider of library version libsymtabAPI.so.10.1, which is gcc-toolset-9-dyninst-10.1.0-1.el8.x86\_64. So I finally ended up with gcc-toolset-9-dyninst-10.1.0-1.el8.x86\_64 being installed in Rocky 8.4 together with all it’s recursive dependencies including the environment-modules-4.5.2-1.el8.x86\_64 package, which messed up with the Lmod installation (from EPEL) from the original CentOS 8.4 . I actually expected the packages in CentOS 8.4 and Rocky 8.4 to be binary compatible, also with respect to the library versions they depend on. Is this a wrong expectation or is this a bug in Rocky’s current systemtap-runtime-4.4-11 package? Best regards Jürgen ---
**Author:** ![jlehtone](https://avatars.discourse-cdn.com/v4/letter/j/e9a140/32.png) [@jlehtone](https://forums.rockylinux.org/u/jlehtone)\ **Post date:** [September 11, 2021, 9:55pm UTC](https://forums.rockylinux.org/t/bug-in-rockys-systemtap-runtime-4-4-11-package/4034/2 "2021-09-11T21:55:20Z")
> [@jsalk](#): > > ```auto > dependency: libsymtabAPI.so.10.2()(64bit) > provider: dyninst-10.2.1-2.el8.x86_64 > provider: gcc-toolset-10-dyninst-10.2.1-2.el8.x86_64 > > ``` > > The `yum deplist` is an alias for > > ```auto > dnf repoquery --deplist > > ``` > > which _“Produce a list of all direct dependencies and what packages provide those dependencies for the given packages. The result only shows the newest providers”_ Both of those packages do provide the `libdyninstAPI.so.10.2`, but the gcc-toolset has it under `/opt/rh/gcc-toolset-10/root`. Each gcc-toolset actually has their own systemtap. The `systemtap-runtime` should use (and can see only) the libraries provided by `dyninst` (unless you `scl enable` the toolset). Since toolsets use `scl` (Software Collections tool) and `scl` now can call `module`, you get the environment-modules … Furthermore, systemtap-runtime should not see the toolset’s `libdyninstAPI.so.10.1` (unless you `scl enable`…) Yes, if `systemtap-runtime-4.4-11` depends on `libdyninstAPI.so.10.1()(64bit)` and not `libdyninstAPI.so.10.2()(64bit)`, then that package’s spec has an error. ---
**Author:** ![jsalk](https://avatars.discourse-cdn.com/v4/letter/j/b5ac83/32.png) [@jsalk](https://forums.rockylinux.org/u/jsalk)\ **Post date:** [September 11, 2021, 11:45pm UTC](https://forums.rockylinux.org/t/bug-in-rockys-systemtap-runtime-4-4-11-package/4034/3 "2021-09-11T23:45:53Z")
Hi, thanks for your response. Well, scl was definitely not enabled in the original CentOS 8.4 system. The `scl-utils` package was not even installed in there, but has been installed automatically as a dependency of `gcc-toolset-9-runtime.x86_64` during the migration process to Rocky 8.4 (together with `environment-modules` which is required by `scl-utils`). I do assume this has happened because the `gcc-toolset-9-runtime` package is the only provider of `libdyninstAPI.so.10.1` on which the `systemtap-runtime-4.4-11` depends in Rocky 8.4. I have now also checked the rpm package files `systemtap-runtime-4.4-11.el8_4.x86_64.rpm` from the CentOS and Alma repos and both of them require library version `libdyninstAPI.so.10.2` rather than `libdyninstAPI.so.10.1`. So I also assume this is a bug in the Rocky rpm package. I am going to file a bug report in the Rocky bugzilla … Best regards Jürgen ---
**Author:** ![label](https://avatars.discourse-cdn.com/v4/letter/l/c5a1d2/32.png) [@label](https://forums.rockylinux.org/u/label)\ **Post date:** [September 12, 2021, 5:41pm UTC](https://forums.rockylinux.org/t/bug-in-rockys-systemtap-runtime-4-4-11-package/4034/4 "2021-09-12T17:41:20Z")
This isn’t a bug of the spec file or the RPM itself. It is a bug in which the order of packages were built to begin with. If packages are not built in a correct order, old libraries are likely to be picked up as a result. This is one of those rare cases where `systemtap` was built/updated before `dyninst`. With that being said, the mirrors should have the fixes soon. Apologies for the mess. ---
**Author:** ![jsalk](https://avatars.discourse-cdn.com/v4/letter/j/b5ac83/32.png) [@jsalk](https://forums.rockylinux.org/u/jsalk)\ **Post date:** [September 13, 2021, 5:55pm UTC](https://forums.rockylinux.org/t/bug-in-rockys-systemtap-runtime-4-4-11-package/4034/5 "2021-09-13T17:55:57Z")
Hi, thank you for the very quick fix. May I add a follow-up question: Is the output of `rpm -qpR package.rpm` always supposed to be _exactly_ the same for one and the same package file from Rocky 8.4 and CentOS 8.4? Or are there differences to be expected without being an indication of broken binary compatibility. I did some spot checks with rpm files from the CentOS 8 and Rocky 8 repos and noticed differences for some of them. Best regard Jürgen ---
**Author:** ![label](https://avatars.discourse-cdn.com/v4/letter/l/c5a1d2/32.png) [@label](https://forums.rockylinux.org/u/label)\ **Post date:** [September 13, 2021, 6:09pm UTC](https://forums.rockylinux.org/t/bug-in-rockys-systemtap-runtime-4-4-11-package/4034/6 "2021-09-13T18:09:18Z")
We build off RHEL 8 sources, so I’m not sure I understand your question. You will need to provide more information. ---
**Author:** ![jsalk](https://avatars.discourse-cdn.com/v4/letter/j/b5ac83/32.png) [@jsalk](https://forums.rockylinux.org/u/jsalk)\ **Post date:** [September 13, 2021, 9:49pm UTC](https://forums.rockylinux.org/t/bug-in-rockys-systemtap-runtime-4-4-11-package/4034/7 "2021-09-13T21:49:01Z")
Hi, ok. I don’t think of explicit package dependencies in the spec files but of automatic library dependencies that are added when a binary package is built and may depend on the build environment. For example, the `perf-4.18.0-305.17.1.el8_4.x86_64.rpm` from CentOS 8 does have an automatic dependency from ```auto libdebuginfod.so.1()(64bit libdebuginfod.so.1(ELFUTILS_0.178)(64bit) ``` while the very same rpm file from Rocky 8 does not. So in CentOS 8.4 the perf binary links against libdebuginfod.so.1 (for whatever reasons) while in Rocky 8.4 it does not: ```auto centos84> ldd /usr/bin/perf | grep libdebug libdebuginfod.so.1 => /lib64/libdebuginfod.so.1 (0x00007ffb98ff6000) centos84> rocky84> ldd /usr/bin/perf | grep libdebug rocky84> ``` Another example would be the `lftp-4.8.4-2.el8.x86_64.rpm` package. The Rocky 8.4 package depends on ```auto libidn2.so.0()(64bit) libidn2.so.0(IDN2_0.0.0)(64bit) ``` while the very same CentOS 8.4 package file does not. A third example would be `gnome-color-manager-3.28.0-3.el8.x86_64.rpm` (among some others) which depends on `libexiv2.so.27` in Rocky 8.4 but on `libexiv2.so.26` in the CentOS 8.4 rpm packages. I also noticed quite a number of rpm packages that depend on `librt.so.1` in CentOS 8.4 but not so in the Rocky 8.4 packages. Does that count as breakage of binary compatibility? Best regards Jürgen ---
**Author:** ![jsalk](https://avatars.discourse-cdn.com/v4/letter/j/b5ac83/32.png) [@jsalk](https://forums.rockylinux.org/u/jsalk)\ **Post date:** [September 13, 2021, 9:50pm UTC](https://forums.rockylinux.org/t/bug-in-rockys-systemtap-runtime-4-4-11-package/4034/8 "2021-09-13T21:50:26Z")
BTW: I currently don’t have access to the binary RPMs from RHEL 8.4, so I have to resort to the CentOS 8.4 packages as reference. ---
**Author:** ![label](https://avatars.discourse-cdn.com/v4/letter/l/c5a1d2/32.png) [@label](https://forums.rockylinux.org/u/label)\ **Post date:** [September 14, 2021, 2:03am UTC](https://forums.rockylinux.org/t/bug-in-rockys-systemtap-runtime-4-4-11-package/4034/9 "2021-09-14T02:03:20Z")
We do not count to breaking of binary compatibility unless it inherently breaks the expected usage of said binaries or libraries. This typically comes down to the order in which the packages were built. In the case of `perf`, that comes from the kernel builds, so I cannot comment on why that link is not there. As for `librt.so.1` this likely occurred as a direct result of us not having i686 packages when we initially started building Rocky, and it also likely happened because of us using the newer `file` package which breaks a lot of the dep solving. The only packages that do not ask for `librt.so.1` right now is: ```auto fuse3-libs gnome-desktop3 pacemaker-cluster-libs pacemaker-libs ``` Those four we can rebuild to verify if librt.so.1 comes back by using an older version of `file` but I cannot guarantee this. ---
**Author:** ![brian](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/brian/32/5777_2.png) [@brian](https://forums.rockylinux.org/u/brian)\ **Post date:** [August 25, 2023, 4:05am UTC](https://forums.rockylinux.org/t/bug-in-rockys-systemtap-runtime-4-4-11-package/4034/10 "2023-08-25T04:05:27Z")
Closed on August 25, 2023, 4:05am UTC