Bug 2727 - elfutils libebl* libs sometimes not found
Summary: elfutils libebl* libs sometimes not found
Status: RESOLVED FIXED
Alias: None
Product: systemtap
Classification: Unclassified
Component: releng (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on:
Blocks: 2231
  Show dependency treegraph
 
Reported: 2006-06-02 16:03 UTC by Frank Ch. Eigler
Modified: 2011-03-16 21:19 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed: 2006-06-15 10:31:13


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Ch. Eigler 2006-06-02 16:03:37 UTC
My personal build of stap routinely fails to find libebl*, and thus give
"Unsupported relocation type" error messages when trying to probe
   module("*").function("*")

This is for a cvs systemtap build configured with an absolute $prefix, and built
jointly via --with-elfutils.  After a successful make/make check/make install,
an ordinary call to "$prefix/bin/stap" or even "$build/stap" fails.  It
appears that the Makefile.am stap_LDFLAGS rpath tricks are not working
consistently.  What are the chances of putting the libebl sublibraries
right into libdw* ?

LD_DEBUG=libs shows this for the $prefix/bin/stap case.  Let me know if more
information is needed to reproduce this.

      2344:    
file=/home/fche/Private/DEVEL/DEVEL-systemtap/BUILD/../INST/lib/systemtap/../lib/systemtap/libebl_i386.so
[0];  needed by
/home/fche/Private/DEVEL/DEVEL-systemtap/BUILD/../INST/lib/systemtap/libdw.so.1 [0]
      2344:
      2344:     file=libebl_i386.so [0];  needed by
/home/fche/Private/DEVEL/DEVEL-systemtap/BUILD/../INST/lib/systemtap/libdw.so.1 [0]
      2344:     find library=libebl_i386.so [0]; searching
      2344:      search
path=/usr/local/lib/systemtap/tls/i686/sse2:/usr/local/lib/systemtap/tls/i686:/usr/local/lib/systemtap/tls/sse2:/usr/local/lib/systemtap/tls:/usr/local/lib/systemtap/i686/sse2:/usr/local/lib/systemtap/i686:/usr/local/lib/systemtap/sse2:/usr/local/lib/systemtap
               (RUNPATH from file
/home/fche/Private/DEVEL/DEVEL-systemtap/BUILD/../INST/lib/systemtap/libdw.so.1)
      2344:       trying file=/usr/local/lib/systemtap/tls/i686/sse2/libebl_i386.so
      2344:       trying file=/usr/local/lib/systemtap/tls/i686/libebl_i386.so
      2344:       trying file=/usr/local/lib/systemtap/tls/sse2/libebl_i386.so
[...]
      2344:       trying file=/usr/local/lib/systemtap/libebl_i386.so
      2344:      search cache=/etc/ld.so.cache
      2344:      search
path=/lib/tls/i686/sse2:/lib/tls/i686:/lib/tls/sse2:/lib/tls:/lib/i686/sse2:/lib/i686:/lib/sse2:/lib:/usr/lib/tls/i686/sse2:/usr/lib/tls/i686:/usr/lib/tls/sse2:/usr/lib/tls:/usr/lib/i686/sse2:/usr/lib/i686:/usr/lib/sse2:/usr/lib
             (system search path)
      2344:       trying file=/lib/tls/i686/sse2/libebl_i386.so
[...]
      2344:       trying file=/usr/lib/sse2/libebl_i386.so
      2344:       trying file=/usr/lib/libebl_i386.so
      2344:
semantic error: cannot find module radeon debuginfo: Unsupported relocation type
Comment 1 Roland McGrath 2006-06-15 08:43:39 UTC
Is that --prefix=/home/fche/Private/DEVEL/DEVEL-systemtap/BUILD/../INST in that
build?  Please always include the exact configure command line verbatim in any
bug report.  The LD_DEBUG output shows it looking in /usr/local/lib/systemtap,
which is consistent with the elfutils libs having been previous built with the
default prefix.  Did you reproduce this failure with a fully clean build?
Comment 2 Frank Ch. Eigler 2006-06-15 10:31:13 UTC
(In reply to comment #1)

> Please always include the exact configure command line verbatim in any
> bug report.  

../src/configure --prefix=/home/fche/Private/DEVEL/DEVEL-systemtap/BUILD/../INST
--with-elfutils=/home/fche/Private/DEVEL/DEVEL-systemtap/elfutils-0.120

> The LD_DEBUG output shows it looking in /usr/local/lib/systemtap,
> which is consistent with the elfutils libs having been previous built with the
> default prefix.  

Yes, except that I never build with the default prefix!

> Did you reproduce this failure with a fully clean build?

Yes.
Comment 3 William Cohen 2006-10-18 21:05:00 UTC
Get similar results.

Configured with following line:

/home/wcohen/stap_testing_200610180830/src/configure
--with-elfutils=/home/wcohen/rh-rpms/BUILD/elfutils-0.124
--prefix=/home/wcohen/stap_testing_200610180830/install
<wcohen> did the "readelf -d stap" in /home/wcohen/stap_testing_

Did a "make" and "make install"

In /home/wcohen/stap_testing_200610180830/install/lib/systemtap found that
libdw.so.1 doesn't have correct rpath or runpath:

$ readelf -d libdw.so.1

Dynamic section at offset 0x1b7f0 contains 27 entries:
  Tag        Type                         Name/Value
[...]
 0x0000000f (RPATH)                      Library rpath: [/usr/local/lib/systemtap]
 0x0000001d (RUNPATH)                    Library runpath: [/usr/local/lib/systemtap]
[...]
Should be using /home/wcohen/stap_testing_200610180830/install/lib/systemtap
Comment 4 Roland McGrath 2006-10-18 21:24:28 UTC
I checked in a build fix that should do it.
Please verify with a clean build.
Comment 5 William Cohen 2006-10-18 21:53:14 UTC
Verified that this fixes the problem.