On Fri, Jun 25, 2010 at 11:25 AM, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
None of the above. Why libtool isn't handling this rpath (and the binaries
created during the build process) correctly when it does in other software.
No, libtool is adding an rpath fine; see below:
So if you have the package somewhere I can help you debug the libtool
issue
and see if we need to do this, if there's a new libtool bug, or if there's
an issue in the way gtk-doc-scanobj is being built in the package.
No, it's not a libtool bug. Please reread my earlier messages, I'm
not sure how I can make this more clear. But I'll rewrite it anyways:
The old glib2.spec:
%build
%configure --disable-gtk-doc --enable-static --with-runtime-libdir=../../%{_lib}
# remove rpaths
sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g'
libtool
sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
Note that libtool is mangled *before* we run make. This works fine if
we don't need to run gtk-doc during the build (but if we do, as if
we're running from a git snapshot, then we get screwed).
If we strip the rpaths *after* we run make, then we're fine. No
rpaths in the final Fedora glib2 RPMS, but we can still run stuff
uninstalled.