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@xxxxxxxxxxxxxxxxx | GPG key ID: 78884778 Jabber: hircus@xxxxxxxxxxxxx | IRC: hircus@xxxxxxxxxxxxxxxx () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
