https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=655
Summary: tell executables in bin where the libraries are
installed
Product: OCL
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: Build system
AssignedTo: orocos-dev [..] ...
ReportedBy: ruben [dot] smits [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0
Created an attachment (id=427)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=427)
patch for executable linking problems
Now the executables in ocl/bin don't know where the libraries it needs are
installed. The attached patch changes the cmakefiles to tell the linker where
the libraries are going to be installed.
Please revise, and commit, or tell me if it's ok to commit.
Ruben
[Bug 655] tell executables in bin where the libraries are instal
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=655
Peter Soetens <peter [..] ...> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |peter [..] ...
--- Comment #1 from Peter Soetens <peter [..] ...> 2009-05-23 14:39:42 ---
(In reply to comment #0)
> Created an attachment (id=427)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=427) [details]
> patch for executable linking problems
>
> Now the executables in ocl/bin don't know where the libraries it needs are
> installed. The attached patch changes the cmakefiles to tell the linker where
> the libraries are going to be installed.
>
> Please revise, and commit, or tell me if it's ok to commit.
>
> Ruben
I have very mixed feelings for using RPATH settings during install. Try to find
one decent open source project which does this in a motivated way.
Read for example http://lists.debian.org/debian-devel/2002/07/msg02030.html
In case you don't install your libraries in /usr/lib or whatever on your
platform, the practice is to modify your LD_LIBRARY_PATH, PATH or ld.so.conf
file.
This is not an 'Orocos specific' bug, you'll have exactly the same issue with
any program you install in an out-of-system path. I must admit that a lot of
users are hitting this, we could add RPATH maybe when the user installs
out-of-system path. Other opinions ?
Peter
[Bug 655] tell executables in bin where the libraries are instal
On May 23, 2009, at 08:39 , Peter Soetens wrote:
> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=655
>
>
> Peter Soetens <peter [..] ...> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |peter [..] ...
>
> --- Comment #1 from Peter Soetens <peter [..] ...>
> 2009-05-23 14:39:42 ---
> (In reply to comment #0)
>> Created an attachment (id=427)
> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=427)
> [details]
>> patch for executable linking problems
>>
>> Now the executables in ocl/bin don't know where the libraries it
>> needs are
>> installed. The attached patch changes the cmakefiles to tell the
>> linker where
>> the libraries are going to be installed.
>>
>> Please revise, and commit, or tell me if it's ok to commit.
>>
>> Ruben
>
> I have very mixed feelings for using RPATH settings during install.
> Try to find
> one decent open source project which does this in a motivated way.
> Read for example http://lists.debian.org/debian-devel/2002/07/msg02030.html
Yes, we strike this regularly also. Seems to be no good answer.
> In case you don't install your libraries in /usr/lib or whatever on
> your
> platform, the practice is to modify your LD_LIBRARY_PATH, PATH or
> ld.so.conf
> file.
We simply use ld.so.conf and ldconfig. Gets the job done, but less
than elegant (particularly as you have to remember to run ldconfig
right after the first time you build a package, to get the libraries
in the list. And rerun it if the list of libraries in a package
changes. Easy to forget).
> This is not an 'Orocos specific' bug, you'll have exactly the same
> issue with
> any program you install in an out-of-system path. I must admit that
> a lot of
> users are hitting this, we could add RPATH maybe when the user
> installs
> out-of-system path. Other opinions ?
Agreed, not Orocos specific. I've had little success with RPATH in the
past, and would prefer to stick with ld.so.conf if only because it is
predictable and has no side-effects. Having said that, ld.so.conf
isn't a long term solution I believe ...
S
[Bug 655] tell executables in bin where the libraries are instal
On May 23, 2009 2:39pm, Peter Soetens <peter [..] ...> wrote:
> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=655
> Peter Soetens peter [..] ...> changed:
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |peter [..] ...
> --- Comment #1 from Peter Soetens peter [..] ...> 2009-05-23
> 14:39:42 ---
> (In reply to comment #0)
> > Created an attachment (id=427)
> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=427) [details]
> > patch for executable linking problems
> >
> > Now the executables in ocl/bin don't know where the libraries it needs
> are
> > installed. The attached patch changes the cmakefiles to tell the linker
> where
> > the libraries are going to be installed.
> >
> > Please revise, and commit, or tell me if it's ok to commit.
> >
> > Ruben
> I have very mixed feelings for using RPATH settings during install. Try
> to find
> one decent open source project which does this in a motivated way.
> Read for example
> http://lists.debian.org/debian-devel/2002/07/msg02030.html
I know ROS is using it, but i don't know if it falls under 'decent open
source project' ;):
http://pr.willowgarage.com/wiki/Manifest#head-efa1f490d657cec35f83154d35...
But if you see ROS as one big package they fall under the first point of
the debian-devel list mail
Maybe we should allow it for the deployer-executables to link to the
liborocos-deployment lib and the liborocos-taskbrowser lib??
> In case you don't install your libraries in /usr/lib or whatever on your
> platform, the practice is to modify your LD_LIBRARY_PATH, PATH or
> ld.so.conf
> file.
> This is not an 'Orocos specific' bug, you'll have exactly the same issue
> with
> any program you install in an out-of-system path. I must admit that a lot
> of
> users are hitting this, we could add RPATH maybe when the user installs
> out-of-system path. Other opinions ?
Maybe make it optional in the buildsystem?
> Peter
> --
> Configure bugmail:
> https://www.fmtc.be/bugzilla/orocos/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
> You are the assignee for the bug.
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
[Bug 655] tell executables in bin where the libraries are instal
Having read a little bit about the RPATH issue i think my patch should
be included since:
>From http://wiki.debian.org/RpathIssue:
Debian's Stance
While there's no policy dictating the accepted use of RPATH, it's been
a general consensus that RPATH use is discouraged, given the
interactions between the above reasons and Debian's way of dealing
with libraries and package dependencies.
Currently, the only generally accepted use of this feature in Debian
is to add non-standard library path (like /usr/lib/<package>) to
libraries that are only intended to be used by the executables or
other libraries within the same source package.
Since the ocl libraries are by default installed in a
non-system-default location, we tell (only) the executables, which are
in the same source package, where to find the 'installed' libraries
using -rpath or -runpath (using runpath still allows to override the
library location using the LD_LIBRARY_PATH environment variable).
Ruben
On Sat, May 23, 2009 at 6:28 PM, <Smits [dot] Ruben [..] ...> wrote:
>
> On May 23, 2009 2:39pm, Peter Soetens <peter [..] ...> wrote:
> > https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=655
> >
> >
> >
> >
> >
> > Peter Soetens peter [..] ...> changed:
> >
> >
> >
> > What |Removed |Added
> >
> > ----------------------------------------------------------------------------
> >
> > CC| |peter [..] ...
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > --- Comment #1 from Peter Soetens peter [..] ...> 2009-05-23 14:39:42 ---
> >
> > (In reply to comment #0)
> >
> > > Created an attachment (id=427)
> >
> > --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=427) [details]
> >
> > > patch for executable linking problems
> >
> > >
> >
> > > Now the executables in ocl/bin don't know where the libraries it needs are
> >
> > > installed. The attached patch changes the cmakefiles to tell the linker where
> >
> > > the libraries are going to be installed.
> >
> > >
> >
> > > Please revise, and commit, or tell me if it's ok to commit.
> >
> > >
> >
> > > Ruben
> >
> >
> >
> > I have very mixed feelings for using RPATH settings during install. Try to find
> >
> > one decent open source project which does this in a motivated way.
> >
> > Read for example http://lists.debian.org/debian-devel/2002/07/msg02030.html
> >
>
> I know ROS is using it, but i don't know if it falls under 'decent open source project' ;):
>
> http://pr.willowgarage.com/wiki/Manifest#head-efa1f490d657cec35f83154d35...
>
> But if you see ROS as one big package they fall under the first point of the debian-devel list mail
>
> Maybe we should allow it for the deployer-executables to link to the liborocos-deployment lib and the liborocos-taskbrowser lib??
>
>
> >
> > In case you don't install your libraries in /usr/lib or whatever on your
> >
> > platform, the practice is to modify your LD_LIBRARY_PATH, PATH or ld.so.conf
> >
> > file.
> >
> >
> >
> > This is not an 'Orocos specific' bug, you'll have exactly the same issue with
> >
> > any program you install in an out-of-system path. I must admit that a lot of
> >
> > users are hitting this, we could add RPATH maybe when the user installs
> >
> > out-of-system path. Other opinions ?
> >
>
> Maybe make it optional in the buildsystem?
>
> >
> > Peter
> >
> >
> >
> > --
> >
> > Configure bugmail: https://www.fmtc.be/bugzilla/orocos/userprefs.cgi?tab=email
> >
> > ------- You are receiving this mail because: -------
> >
> > You are on the CC list for the bug.
> >
> > You are the assignee for the bug.
> >
> > --
> >
> > Orocos-Dev mailing list
> >
> > Orocos-Dev [..] ...
> >
> > http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
> >
[Bug 655] tell executables in bin where the libraries are instal
On May 23, 2009, at 14:00 , Ruben Smits wrote:
> Having read a little bit about the RPATH issue i think my patch should
> be included since:
>
>> From http://wiki.debian.org/RpathIssue:
>
> Debian's Stance
>
> While there's no policy dictating the accepted use of RPATH, it's been
> a general consensus that RPATH use is discouraged, given the
> interactions between the above reasons and Debian's way of dealing
> with libraries and package dependencies.
>
> Currently, the only generally accepted use of this feature in Debian
> is to add non-standard library path (like /usr/lib/<package>) to
> libraries that are only intended to be used by the executables or
> other libraries within the same source package.
>
>
> Since the ocl libraries are by default installed in a
> non-system-default location, we tell (only) the executables, which are
> in the same source package, where to find the 'installed' libraries
> using -rpath or -runpath (using runpath still allows to override the
> library location using the LD_LIBRARY_PATH environment variable).
What effect will this have on user application code that needs to link
against OCL's libraries? We would need to add the library path to
ld.so.conf still?
S
[Bug 655] tell executables in bin where the libraries are instal
On Sat, May 23, 2009 at 8:14 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
> On May 23, 2009, at 14:00 , Ruben Smits wrote:
>
> Having read a little bit about the RPATH issue i think my patch should
>> be included since:
>>
>> From http://wiki.debian.org/RpathIssue:
>>>
>>
>> Debian's Stance
>>
>> While there's no policy dictating the accepted use of RPATH, it's been
>> a general consensus that RPATH use is discouraged, given the
>> interactions between the above reasons and Debian's way of dealing
>> with libraries and package dependencies.
>>
>> Currently, the only generally accepted use of this feature in Debian
>> is to add non-standard library path (like /usr/lib/<package>) to
>> libraries that are only intended to be used by the executables or
>> other libraries within the same source package.
>>
>>
>> Since the ocl libraries are by default installed in a
>> non-system-default location, we tell (only) the executables, which are
>> in the same source package, where to find the 'installed' libraries
>> using -rpath or -runpath (using runpath still allows to override the
>> library location using the LD_LIBRARY_PATH environment variable).
>>
>
> What effect will this have on user application code that needs to link
> against OCL's libraries? We would need to add the library path to ld.so.conf
> still?
> S
>
> None i think, since it will only be used for the deployer and taskbrowser
executables, not for the libraries itself. For the application code, the
application builder must decide for himself, he can add the rpath and live
with the concequences or does not and add the path's to the ld.so.conf or
LD_LIBRARY_PATH.
At least that's what i think, i hope i'm right on this.
Ruben