Bug 1498389 - devtoolset-7-dyninst needs the -devel package installed
Summary: devtoolset-7-dyninst needs the -devel package installed
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Developer Toolset
Classification: Red Hat
Component: doc-Release_Notes
Version: DTS 7.0 RHEL 7
Hardware: Unspecified
OS: Linux
low
low
Target Milestone: alpha
: 7.0
Assignee: Lenka Špačková
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 1498558
TreeView+ depends on / blocked
 
Reported: 2017-10-04 08:10 UTC by Martin Cermak
Modified: 2017-10-30 12:50 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
When the user installs only the devtoolset-7-dyninst or devtoolset-7-systemtap packages, the devtoolset-7-dyninst-devel package is not pulled. As a consequence, Dyninst fails to work correctly. The same problem applies also to SystemTap with the Dyninst back end when the "stap --dyninst" command is used. To work around this problem, manually install the devtoolset-7-dyninst-devel package, enable the devtoolset-7 collection, and then run the "ldconfig" command.
Clone Of:
: 1498558 (view as bug list)
Environment:
Last Closed: 2017-10-30 12:50:28 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Martin Cermak 2017-10-04 08:10:10 UTC
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.

Comment 3 Frank Ch. Eigler 2017-10-04 14:53:04 UTC
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?

Comment 4 Frank Ch. Eigler 2017-10-04 15:05:26 UTC
The simplest workaround for the user is to run

# ldconfig

after installing dyninst/systemtap.  No need for the dyninst-devel subrpm.

Comment 5 Martin Cermak 2017-10-04 15:37:18 UTC
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 ~]#
=======

Comment 6 Stan Cox 2017-10-11 14:49:44 UTC
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)


Note You need to log in before you can comment on or make changes to this bug.