It turns out that for dyninst to work correctly, the user needs to install the dyninst-devel package and perform the `ldconfig` command after that. The same applies when one wants to run systemtap with the dyninst backend (stap --dyninst). The user will not hit this issue in case she installs devtoolset-7\*. But the issue pops up once the user installs devtoolset-7-dyninst only, or devtoolset-7-systemtap only (with their rpm deps). In such case the -devel package doesn't get pulled in, and needs to be installed by hand. Please, turn this report into a known issue. Thanks.
It seems the only problem here is that the ldconfig program doesn't run effectively for the /usr/lib*/dyninst directory. e.g., on f26, the lrwxrwxrwx. 1 root root 25 Jul 5 22:06 libdyninstAPI_RT.so.9.3 -> libdyninstAPI_RT.so.9.3.2 symlink does not need to - should not - come from the dyninst-devel nor dyninst subrpms. # ldconfig -v creates them all just fine, with /etc/ld.so.conf.d/dyninst-x86_64.conf set. Maybe the dyninst spec just lacks "ldconfig" in its %post?
The simplest workaround for the user is to run # ldconfig after installing dyninst/systemtap. No need for the dyninst-devel subrpm.
I fear the above is not true. Here is what I see with fresh rhel-7.4 installation (having coreutils-debuginfo): ======= [root@qeos-74 ~]# stap --dyninst -e 'probe process.function("main") {println("HIT")}' -c /bin/ls --FATAL-- #68: Dyninst was unable to create the specified process --FATAL-- #68: create process failed bootstrap stapdyn: ERROR: Couldn't create the target process WARNING: /usr/bin/stapdyn exited with status: 1 Pass 5: run failed. [man error::pass5] [root@qeos-74 ~]# ldconfig [root@qeos-74 ~]# stap --dyninst -e 'probe process.function("main") {println("HIT")}' -c /bin/ls --FATAL-- #68: Dyninst was unable to create the specified process --FATAL-- #68: create process failed bootstrap stapdyn: ERROR: Couldn't create the target process WARNING: /usr/bin/stapdyn exited with status: 1 Pass 5: run failed. [man error::pass5] [root@qeos-74 ~]# yum install dyninst-devel -y >/dev/null [root@qeos-74 ~]# stap --dyninst -e 'probe process.function("main") {println("HIT")}' -c /bin/ls stapdyn: WARNING: Couldn't instrument the function containing 0x4029b0, /usr/bin/ls+0x29b0 anaconda-ks.cfg install.time original-ks.cfg set-hostname [root@qeos-74 ~]# =======
I noticed a couple of things doing some experimenting: * dyninst 9.3.1 library handling * libdyninstAPI_RT.so is the dyninst runtime library * loaded dynamically * stapdyn/dynutil.cxx::check_dyninst_rt * checks environment variable DYNINSTAPI_RT_LIB * otherwise uses dir where libdyninstAPI.so is located /opt/rh/devtoolset-7/root/usr/lib64/dyninst/libdyninstAPI_RT.so.9.3 * upstream sets environment variable DYNINST_REWRITER_PATHS * previously was setting DYNINST_RT_LIB * dyninstAPI/src/linux.C::BinaryEdit::getResolvedLibraryPath * checks DYNINST_REWRITER_PATHS, LD_LIBRARY_PATH, ldconfig -p * but systemtap 3.1-3 still sets DYNINSTAPI_RT_LIB * so next tries LD_LIBRARY_PATH /opt/rh/devtoolset-7/root/usr/lib64:/opt/rh/devtoolset-7/root/usr/lib * so next tries ldconfig -p * finds /usr/lib64/dyninst/libdyninstAPI_RT.so and uses that * (only the runtime library is found this way) * other dyninst libraries are in executable's dynamic library list libpcontrol.so.9.3 => /opt/rh/devtoolset-7/root/usr/lib64/dyninst/libpcontrol.so.9.3 * ldconfig effects * devtoolset adds to ldconfig /opt/rh/devtoolset-7/root/usr/lib64/dyninst * ldconfig -p | /usr/bin/grep dyninstAPI.so libdyninstAPI.so.9.3 (libc6,x86-64) => /opt/rh/devtoolset-7/root/usr/lib64/dyninst/libdyninstAPI.so.9.3 libdyninstAPI.so.9.3 (libc6,x86-64) => /usr/lib64/dyninst/libdyninstAPI.so.9.3 libdyninstAPI.so (libc6,x86-64) => /opt/rh/devtoolset-7/root/usr/lib64/dyninst/libdyninstAPI.so libdyninstAPI.so (libc6,x86-64) => /usr/lib64/dyninst/libdyninstAPI.so * if devtoolset has not been invoked (via 'scl enable devtoolset-7 bash') * the devtoolset shared library gets linked in: g++ mutator.cpp -L/usr/lib64/dyninst -ldyninstAPI -o mutator.x -g -I/usr/include/dyninst ; ldd mutator.x | /usr/bin/grep dyninstAPI.so libdyninstAPI.so.9.3 => /opt/rh/devtoolset-7/root/usr/lib64/dyninst/libdyninstAPI.so.9.3 (0x00007f68950f4000)
The book has been published: https://access.redhat.com/documentation/en-us/red_hat_developer_toolset/7/html/7.0_release_notes/dts7.0_release#Known_Issues