Bug 1498389

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