[Fedora-packaging] Updating our rpath guidelines?

[Toshio Kuratomi]

On Tue, Nov 09, 2010 at 07:43:11PM +0000, Michel Alexandre Salim wrote:
> On Mon, 08 Nov 2010 17:45:26 -0800, Toshio Kuratomi wrote:
> 
> > On Mon, Nov 08, 2010 at 12:57:21PM +0000, Michel Alexandre Salim wrote:
> >> On Sun, 07 Nov 2010 12:45:07 -0500, Orcan Ogetbil wrote:
> >> 
> >> > On Sat, Nov 6, 2010 at 10:03 PM, Michel Alexandre Salim wrote:
> >> >> Hi all,
> >> >>
> >> >> Several months ago, Mamoru Tasaka suggested a less intrusive way of
> >> >> patching a source package's bundled libtool so that /usr/lib64 does
> >> >> not end up in the installed binaries.
> >> >>
> >> >>       So actually for most cases, the case that rpath /usr/lib64
> >> >>       is added (only for 64 bits arch) can be avoided by
> >> >> 
> >> 
> ------------------------------------------------------------------------
> >> >> sed -i.libdir_syssearch -e \
> >> >>   '/sys_lib_dlsearch_path_spec/s|/usr/lib |/usr/lib /usr/lib64 /lib
> >> >>   /lib64 |' \ configure
> >> >> 
> >> 
> ------------------------------------------------------------------------
> >> >>       i.e. just add the needed paths to
> >> >>       sys_lib_dlsearch_path_spec in configure (note that libtool
> >> >>       in the build directory is generated by configure) before
> >> >>       calling %configure. - You can alternatively do "autoreconf
> >> >>       -fi", however calling autotools
> >> >>         is not recommended unless unavoidable.
> >> >> ----------
> >> >>
> >> >> I have several packages using the old-style DIE_RPATH_DIE
> >> >> (http://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath)
> >> >> sed hack, and while they've been working out fine so far, I just
> >> >> noticed when updating Vala today that this rather invasive change is
> >> >> responsible for Vala's test suite not to run: since the Vala
> >> >> libraries have not been installed on the system when the tests were
> >> >> run, Rpath is actually necessary to run the tests!
> >> >>
> >> >>
> >> > Did you try LD_PRELOAD or LD_LIBRARY_PATH? Something like
> >> > 
> >> > %check
> >> > cd tests/
> >> > LD_LIBRARY_PATH=../src/.libs ./run_tests
> >> > 
> >> That'd probably work, yes, but given that one needs to stop /usr/lib64
> >> from appearing in the rpath of the installed binaries anyway, surely
> >> one clean fix is better than two hackish ones?
> >> 
> >> If we update the guideline, then upstream's build scripts should *just
> >> work* (unless it's the Mono stack where /lib is hardcoded all over the
> >> place...)
> >> 
> > So the rpath is pointing to the temporary location where the library was
> > built?  If so, those rpaths don't belong either (as they expose you to
> > potential security problems if someone puts a library into that
> > directory on a running production system).
> > 
> No, the installed binaries don't have any rpaths at all (because the 
> missing *lib64 paths have been added to ldconfig so it does not assume 
> they are custom library paths)
> 
> The problem, I think, has to do with how LD_RUN_PATH is no longer added 
> to runpath_var (see the DIE_RPATH_DIE line).
> 
> The 'make check' target for Vala basically link the vala compiler binary 
> twice: once for testing, using LD_RUN_PATH to point it to the build libs 
> directory, and once for installation, without LD_RUN_PATH.
> 
That sounds like vala's build is doing something non-standard then so you
could use the targetted sed line here without problems or LD_LIBRARY_PATH
with the current sed change but it also sounds like the targetted sed change
will miss a bunch of things that the current guidelines do not so we should
probably not change the guidelines.

about the hackiness factor, to me, using LD_LIBRARY_PATH for the testing is
less hacky than relinking the binary in the check and in the install
phase.  Perhaps upstream would take a patch to use LD_LIBRARY_PATH instead
of current relinking?

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20101109/5398d54d/attachment.bin