On Fri, Jun 25, 2010 at 11:25 AM, Toshio Kuratomi <a.badger@xxxxxxxxx> 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.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
