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 Of course the library directory in the build tree and the tests executable is probably different. Orcan -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
