rpath handling

[Colin Walters]

On Fri, Jun 25, 2010 at 11:25 AM, Toshio Kuratomi <a.badger at 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.