Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=429435
--- Comment #20 from Lubomir Rintel <lkundrak(a)v3.sk> 2008-12-29 11:50:40 EDT ---
(In reply to comment #19)
> You're wrong here. The libgnubversion.so.0 really needs to
go to _libdir,
> unlike
> libnautilus-gnubversion.so, which should stay in nautilus extension directory.
>
> Please move it. Thanks!
Well, no. It can be guessed that the fact that this software
(or the upstream) tries to install libgnubversion.so.0 under %_libdir/%name
means that this software should work (at least for the upstream)
without moving the library into %_libdir (well, there are not a few
cases in which upstream make mistakes, however this is not
the case).
The culprit is the following lines.
----------------------------------------------------------
#Remove Rpath
sed -i 's|^hardcode_libdir_flag_spec="\\${wl}--rpath
\\${wl}\\$libdir"|hardcode_libdir_flag_spec=""|g' libtool
sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
-----------------------------------------------------------
Well, I see these lines in many spec files, however this method
removes _all_ rpaths, which sometimes makes the software
unusable like this case and bug 432468.
The unneeded rpath _only_ should be removed
(on x86_64 it is /usr/lib64, on i386 there is nothing on this package) and
%_libdir/%name rpath should be preserved, and libgnubversion.so.0
should not be moved to %_libdir. Refer to anjuta spec file about
how to deal with this for example.
I still tend to disagree. There's really no good reason for that library not
being in libdir. Well, upstream does that, but that's a pretty bad excuse for
using RPATH, though a good reason for a bug report upstream.
--
Configure bugmail:
https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.