Hi -
I have a question regarding commit e219f1c1b2 (by roland, from pre-git days)
that changed the way libdw/libdw.so is linked:
@@ -94,7 +93,10 @@ libdw_so_SOURCES =
libdw.so: $(srcdir)/libdw.map libdw_pic.a \
../libdwfl/libdwfl_pic.a ../libebl/libebl.a \
../libelf/libelf.so
+# The rpath is necessary for libebl because its $ORIGIN use will
+# not fly in a setuid executable that links in libdw.
$(LINK) -shared -o $@ -Wl,--soname,$@.$(VERSION),-z,defs \
+ -Wl,--enable-new-dtags,-rpath,$(pkglibdir) \
-Wl,--version-script,$<,--no-undefined \
-Wl,--whole-archive $(filter-out $<,$^) -Wl,--no-whole-archive\
-ldl
This construct conflicts with the bundled-elfutils mode of systemtap
linkage (also written by roland back in '08), where that $(pkglibdir)
is made to have build-tree paths rather than install-tree paths: (from
systemtap top-level configure.ac)
# Our libdw.so's libebl will look in $ORIGIN/../lib/... but that
# $ORIGIN is where libdw.so resides, which is not where there is a ../lib.
# Note that $libdir might be using a quoted use of $exec_prefix or $prefix.
# So we must make sure to pass those settings to elfutils configure.
elfutils_rpath="-Wl,--enable-new-dtags,-rpath,${libdir}/${PACKAGE_NAME}"
here=`pwd`
(mkdir -p build-elfutils && cd build-elfutils &&
bash ${elfutils_srcdir}/configure --enable-libebl-subdir=${PACKAGE_NAME} \
--includedir="${here}/include-elfutils" \
--libdir="${here}/lib-elfutils" \
--exec-prefix="$exec_prefix" \
--prefix="$prefix" \
CFLAGS="${CFLAGS/-Wall/} $gnu89_inline_flag" \
LDFLAGS="$LDFLAGS $elfutils_rpath" &&
This in turn propagates build-tree DT_R*PATH into the .so files.
There appear to be no tools able to remove those erroneous paths.
Is there still a need for the libdw custom rpath usage? I don't know
of any setuid users of -ldw.
- FChE