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!
Given that there are probably other packages where internal test suites depend on a currently-uninstalled shared library, updating the Rpath guidelines ought to have positive effect on packaging quality. We should probably also search for occurences of the old DIE_RPATH_DIE and convert them to the new format.
Best regards,
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
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...)
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).
-Toshio
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.
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
packaging@lists.fedoraproject.org