[Fedora-packaging] Updating our rpath guidelines?

Michel Alexandre Salim salimma at fedoraproject.org
Tue Nov 9 19:43:11 UTC 2010


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.

-- 
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email:  salimma at fedoraproject.org  | GPG key ID: 78884778
Jabber: hircus at jabber.ccc.de       | IRC: hircus at irc.freenode.net

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments



More information about the packaging mailing list