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