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
Attachment:
pgpyV67vFkELQ.pgp
Description: PGP signature
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
