Re: rpath handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux