FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 11-07-2010, 01:03 AM
Michel Alexandre Salim
 
Default Updating our rpath guidelines?

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,

--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email: salimma@fedoraproject.org | GPG key ID: 78884778
Jabber: hircus@jabber.ccc.de | IRC: hircus@irc.freenode.net

() ascii ribbon campaign - against html e-mail
/ www.asciiribbon.org - against proprietary attachments
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 11-07-2010, 04:45 PM
Orcan Ogetbil
 
Default Updating our rpath guidelines?

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 11-08-2010, 11:57 AM
Michel Alexandre Salim
 
Default Updating our rpath guidelines?

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...)

--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email: salimma@fedoraproject.org | GPG key ID: 78884778
Jabber: hircus@jabber.ccc.de | IRC: hircus@irc.freenode.net

() ascii ribbon campaign - against html e-mail
/ www.asciiribbon.org - against proprietary attachments

--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 11-09-2010, 12:45 AM
Toshio Kuratomi
 
Default Updating our rpath guidelines?

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
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 11-09-2010, 06:43 PM
Michel Alexandre Salim
 
Default Updating our rpath guidelines?

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@fedoraproject.org | GPG key ID: 78884778
Jabber: hircus@jabber.ccc.de | IRC: hircus@irc.freenode.net

() ascii ribbon campaign - against html e-mail
/ www.asciiribbon.org - against proprietary attachments

--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 11-09-2010, 07:25 PM
Toshio Kuratomi
 
Default Updating our rpath guidelines?

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 mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 

Thread Tools




All times are GMT. The time now is 04:07 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org