Looking at the trunk/ocl/config/FindKDL.cmake file, I noticed that the kdltk
shared library plugin is set as a dependency of the OCL in the orocos-ocl.pc
file. This is certainly unwanted, because this will cause applications to
link with the plugin, which is installed in a non standard library path
(lib/rtt/plugins). Hence these applications will fail to run.
The code I would remove is:
SET(ENV{PKG_CONFIG_PATH} "${KDL_INSTALL}/lib/pkgconfig/:
${OROCOS_INSTALL}/lib/pkgconfig")
MESSAGE( "Looking for KDL Toolkit in: ${PKG_CONFIG_PATH}")
PKGCONFIG( "orocos-kdltk-${OROCOS_TARGET} >= 0.99" KDLTK_FOUND
KDLTK_INCLUDE_DIRS KDLTK_DEFINES KDLTK_LINK_DIRS KDLTK_LIBS )
IF(KDLTK_FOUND)
INCLUDE_DIRECTORIES( ${KDLTK_INCLUDE_DIRS} )
LINK_DIRECTORIES( ${KDLTK_LINK_DIRS})
OROCOS_PKGCONFIG_INCPATH("${KDLTK_INCLUDE_DIRS}")
OROCOS_PKGCONFIG_LIBPATH("${KDLTK_LINK_DIRS}")
OROCOS_PKGCONFIG_LIBS("${KDLTK_LIBS}")
IF(CORBA_ENABLED)
SET(ENV{PKG_CONFIG_PATH} "${KDL_INSTALL}/lib/pkgconfig/:
${OROCOS_INSTALL}/lib/pkgconfig")
MESSAGE("Looking for KDL Toolkit CORBA extension in ${PKG_CONFIG_PATH}")
PKGCONFIG( "orocos-kdltk-corba-${OROCOS_TARGET} >= 0.99" KDLTKCOR
I don't understand why it's in there, or why it is needed[*], but it should be
gone. It breaks applications.
Peter
[*] maybe
OCL dependencies on KDL & kdltk-plugin
On Wednesday 17 September 2008 09:48:53 Peter Soetens wrote:
> Looking at the trunk/ocl/config/FindKDL.cmake file, I noticed that the
> kdltk shared library plugin is set as a dependency of the OCL in the
> orocos-ocl.pc file. This is certainly unwanted, because this will cause
> applications to link with the plugin, which is installed in a non standard
> library path (lib/rtt/plugins). Hence these applications will fail to run.
>
> The code I would remove is:
>
> SET(ENV{PKG_CONFIG_PATH} "${KDL_INSTALL}/lib/pkgconfig/:
> ${OROCOS_INSTALL}/lib/pkgconfig")
> MESSAGE( "Looking for KDL Toolkit in: ${PKG_CONFIG_PATH}")
> PKGCONFIG( "orocos-kdltk-${OROCOS_TARGET} >= 0.99" KDLTK_FOUND
> KDLTK_INCLUDE_DIRS KDLTK_DEFINES KDLTK_LINK_DIRS KDLTK_LIBS )
> IF(KDLTK_FOUND)
> INCLUDE_DIRECTORIES( ${KDLTK_INCLUDE_DIRS} )
> LINK_DIRECTORIES( ${KDLTK_LINK_DIRS})
isn't removing these three lines sufficient?
OROCOS_PKGCONFIG_INCPATH("${KDLTK_INCLUDE_DIRS}")
OROCOS_PKGCONFIG_LIBPATH("${KDLTK_LINK_DIRS}")
OROCOS_PKGCONFIG_LIBS("${KDLTK_LIBS}")
Ruben ?
> IF(CORBA_ENABLED)
> SET(ENV{PKG_CONFIG_PATH} "${KDL_INSTALL}/lib/pkgconfig/:
> ${OROCOS_INSTALL}/lib/pkgconfig")
> MESSAGE("Looking for KDL Toolkit CORBA extension in
> ${PKG_CONFIG_PATH}") PKGCONFIG( "orocos-kdltk-corba-${OROCOS_TARGET} >=
> 0.99" KDLTKCOR
>
> I don't understand why it's in there, or why it is needed[*], but it should
> be gone. It breaks applications.
>
> Peter
> [*] maybe
> --
> Peter Soetens -- FMTC --
OCL dependencies on KDL & kdltk-plugin
On Wednesday 17 September 2008 09:56:09 Ruben Smits wrote:
> On Wednesday 17 September 2008 09:48:53 Peter Soetens wrote:
> > Looking at the trunk/ocl/config/FindKDL.cmake file, I noticed that the
> > kdltk shared library plugin is set as a dependency of the OCL in the
> > orocos-ocl.pc file. This is certainly unwanted, because this will cause
> > applications to link with the plugin, which is installed in a non
> > standard library path (lib/rtt/plugins). Hence these applications will
> > fail to run.
> >
> > The code I would remove is:
> >
> > SET(ENV{PKG_CONFIG_PATH} "${KDL_INSTALL}/lib/pkgconfig/:
> > ${OROCOS_INSTALL}/lib/pkgconfig")
> > MESSAGE( "Looking for KDL Toolkit in: ${PKG_CONFIG_PATH}")
> > PKGCONFIG( "orocos-kdltk-${OROCOS_TARGET} >= 0.99" KDLTK_FOUND
> > KDLTK_INCLUDE_DIRS KDLTK_DEFINES KDLTK_LINK_DIRS KDLTK_LIBS )
> > IF(KDLTK_FOUND)
> > INCLUDE_DIRECTORIES( ${KDLTK_INCLUDE_DIRS} )
> > LINK_DIRECTORIES( ${KDLTK_LINK_DIRS})
>
> isn't removing these three lines sufficient?
> OROCOS_PKGCONFIG_INCPATH("${KDLTK_INCLUDE_DIRS}")
> OROCOS_PKGCONFIG_LIBPATH("${KDLTK_LINK_DIRS}")
> OROCOS_PKGCONFIG_LIBS("${KDLTK_LIBS}")
No. I don't see why *any* component should link with a plugin in a non
standard library path. The kdltk plugin is intended to be located and loaded
at runtime by the deployer (or ctaskbrowser in a later version) As a matter
of fact, the whole orocos-kdltk-*.pc files should be gone. A .pc file is for
a library in /usr/lib, not for a plugin in a subdirectory.
For my part, the plugin loading may be moved from the deployer to the RTT. In
that way, every application has access to it, using deployer or not.
Peter
OCL dependencies on KDL & kdltk-plugin
On Wednesday, September 17, 2008, at 11:46AM, "Peter Soetens"
<peter [dot] soetens [..] ...> wrote:
>On Wednesday 17 September 2008 09:56:09 Ruben Smits wrote:
>> On Wednesday 17 September 2008 09:48:53 Peter Soetens wrote:
>> > Looking at the trunk/ocl/config/FindKDL.cmake file, I noticed that the
>> > kdltk shared library plugin is set as a dependency of the OCL in the
>> > orocos-ocl.pc file. This is certainly unwanted, because this will cause
>> > applications to link with the plugin, which is installed in a non
>> > standard library path (lib/rtt/plugins). Hence these applications will
>> > fail to run.
>> >
>> > The code I would remove is:
>> >
>> > SET(ENV{PKG_CONFIG_PATH} "${KDL_INSTALL}/lib/pkgconfig/:
>> > ${OROCOS_INSTALL}/lib/pkgconfig")
>> > MESSAGE( "Looking for KDL Toolkit in: ${PKG_CONFIG_PATH}")
>> > PKGCONFIG( "orocos-kdltk-${OROCOS_TARGET} >= 0.99" KDLTK_FOUND
>> > KDLTK_INCLUDE_DIRS KDLTK_DEFINES KDLTK_LINK_DIRS KDLTK_LIBS )
>> > IF(KDLTK_FOUND)
>> > INCLUDE_DIRECTORIES( ${KDLTK_INCLUDE_DIRS} )
>> > LINK_DIRECTORIES( ${KDLTK_LINK_DIRS})
>>
>> isn't removing these three lines sufficient?
>> OROCOS_PKGCONFIG_INCPATH("${KDLTK_INCLUDE_DIRS}")
>> OROCOS_PKGCONFIG_LIBPATH("${KDLTK_LINK_DIRS}")
>> OROCOS_PKGCONFIG_LIBS("${KDLTK_LIBS}")
>
>No. I don't see why *any* component should link with a plugin in a non
>standard library path. The kdltk plugin is intended to be located and loaded
>at runtime by the deployer (or ctaskbrowser in a later version) As a matter
>of fact, the whole orocos-kdltk-*.pc files should be gone. A .pc file is for
>a library in /usr/lib, not for a plugin in a subdirectory.
>
>For my part, the plugin loading may be moved from the deployer to the RTT. In
>that way, every application has access to it, using deployer or not.
I believe that I might have added the lines to the ocl/config/FindKDL.cmake file that started this discussion. IIRC (and this is dim, it was a few months ago), I had to add those to deal with libraries that used KDLTK that were loaded/run by the deployer. The problem started with the deployer not loading plugins as the default directory was fixed (I have Orocos in a non-standard location), but it may have progressed to more than just this as the problem. I don't quite remember, but I strongly remember having to add some way to get that plugin into the runtime system to actually get the application to startup.
I believe that my situation also also negates Peter's first comment above. Because I have Orocos installed in a non-standard location (ie not /usr) then I will, by default, have components that need a plugin from a non-standard library path, right?
HTH
S
OCL dependencies on KDL & kdltk-plugin
On Thursday 18 September 2008 16:31:20 S Roderick wrote:
<peter [dot] soetens [..] ...> wrote:> On Wednesday, September 17, 2008, at 11:46AM, "Peter Soetens"
> >On Wednesday 17 September 2008 09:56:09 Ruben Smits wrote:
> >> On Wednesday 17 September 2008 09:48:53 Peter Soetens wrote:
> >> > Looking at the trunk/ocl/config/FindKDL.cmake file, I noticed that the
> >> > kdltk shared library plugin is set as a dependency of the OCL in the
> >> > orocos-ocl.pc file. This is certainly unwanted, because this will
> >> > cause applications to link with the plugin, which is installed in a
> >> > non standard library path (lib/rtt/plugins). Hence these applications
> >> > will fail to run.
> >> >
> >> > The code I would remove is:
> >> >
> >> > SET(ENV{PKG_CONFIG_PATH} "${KDL_INSTALL}/lib/pkgconfig/:
> >> > ${OROCOS_INSTALL}/lib/pkgconfig")
> >> > MESSAGE( "Looking for KDL Toolkit in: ${PKG_CONFIG_PATH}")
> >> > PKGCONFIG( "orocos-kdltk-${OROCOS_TARGET} >= 0.99" KDLTK_FOUND
> >> > KDLTK_INCLUDE_DIRS KDLTK_DEFINES KDLTK_LINK_DIRS KDLTK_LIBS )
> >> > IF(KDLTK_FOUND)
> >> > INCLUDE_DIRECTORIES( ${KDLTK_INCLUDE_DIRS} )
> >> > LINK_DIRECTORIES( ${KDLTK_LINK_DIRS})
> >>
> >> isn't removing these three lines sufficient?
> >> OROCOS_PKGCONFIG_INCPATH("${KDLTK_INCLUDE_DIRS}")
> >> OROCOS_PKGCONFIG_LIBPATH("${KDLTK_LINK_DIRS}")
> >> OROCOS_PKGCONFIG_LIBS("${KDLTK_LIBS}")
Just like with RTT's pc file, the OCL should have a Libs.private section as
well. The attached patch fixes these issues for KDL/BFL in my opinion.
Peter
OCL dependencies on KDL & kdltk-plugin
On Friday 19 September 2008 09:13:00 Ruben Smits wrote:
> On Thursday 18 September 2008 17:41:01 Peter Soetens wrote:
> > On Thursday 18 September 2008 16:31:20 S Roderick wrote:
> > > On Wednesday, September 17, 2008, at 11:46AM, "Peter Soetens"
> >
> >
<peter [dot] soetens [..] ...> wrote:
> > > >On Wednesday 17 September 2008 09:56:09 Ruben Smits wrote:
> > > >> On Wednesday 17 September 2008 09:48:53 Peter Soetens wrote:
> > > >> > Looking at the trunk/ocl/config/FindKDL.cmake file, I noticed that
> > > >> > the kdltk shared library plugin is set as a dependency of the OCL
> > > >> > in the orocos-ocl.pc file. This is certainly unwanted, because
> > > >> > this will cause applications to link with the plugin, which is
> > > >> > installed in a non standard library path (lib/rtt/plugins). Hence
> > > >> > these applications will fail to run.
> > > >> >
> > > >> > The code I would remove is:
> > > >> >
> > > >> > SET(ENV{PKG_CONFIG_PATH} "${KDL_INSTALL}/lib/pkgconfig/:
> > > >> > ${OROCOS_INSTALL}/lib/pkgconfig")
> > > >> > MESSAGE( "Looking for KDL Toolkit in: ${PKG_CONFIG_PATH}")
> > > >> > PKGCONFIG( "orocos-kdltk-${OROCOS_TARGET} >= 0.99" KDLTK_FOUND
> > > >> > KDLTK_INCLUDE_DIRS KDLTK_DEFINES KDLTK_LINK_DIRS KDLTK_LIBS )
> > > >> > IF(KDLTK_FOUND)
> > > >> > INCLUDE_DIRECTORIES( ${KDLTK_INCLUDE_DIRS} )
> > > >> > LINK_DIRECTORIES( ${KDLTK_LINK_DIRS})
> > > >>
> > > >> isn't removing these three lines sufficient?
> > > >> OROCOS_PKGCONFIG_INCPATH("${KDLTK_INCLUDE_DIRS}")
> > > >> OROCOS_PKGCONFIG_LIBPATH("${KDLTK_LINK_DIRS}")
> > > >> OROCOS_PKGCONFIG_LIBS("${KDLTK_LIBS}")
> >
> > Just like with RTT's pc file, the OCL should have a Libs.private section
> > as well. The attached patch fixes these issues for KDL/BFL in my opinion.
>
> It looks ok, but did you test that the components which are using KDL
> (motion_control) are still compiling and running?
They compiled/loaded fine, but, as to be expected, the deployer needed the kdl
plugin loading from its 'ComponentPath' to know the kdl types which gave:
31.401 [ Info ][deployer-gnulinux::main()] Loading plugins
from /usr/local/lib/rtt/gnulinux/plugins
33.824 [ Info ][DeploymentComponent::loadLibrary] Loading CorbaKDL in RTT
type system.
33.830 [ Info ][DeploymentComponent::loadLibrary] Loaded RTT
Plugin 'CorbaKDL'
33.831 [ Info ][Toolkit] Loading Tool KDL.
33.831 [ Info ][Toolkit] Registered new 'CORBA' transport for frame
33.831 [ Info ][Toolkit] Registered new 'CORBA' transport for rotation
33.831 [ Info ][Toolkit] Registered new 'CORBA' transport for vector
33.831 [ Info ][Toolkit] Registered new 'CORBA' transport for twist
33.831 [ Info ][Toolkit] Registered new 'CORBA' transport for wrench
33.868 [ Info ][DeploymentComponent::loadLibrary] Loaded RTT Plugin 'KDL'
After which the types were known. The 'old' solution was linking your
component with the kdltk library, but since this library is in a non-standard
path, that is no longer an option. So I modified their CMakeLists.txt files
as well.
In the long term, I see these solutions:
* Move plugin loading to the RTT, in ORO_main()
* Provide a public API to 'manually' load plugins (for non standard paths,
plugin names)
* Provide a public API to allow components to specify plugin requirements.
(like: RTT::Toolkit::Requires("KDL"); ). Which will check if this plugin is
available and print a warning if it is not available.
That should make future component robust against most potential loading/path
problems.
Good idea ?
Peter
OCL dependencies on KDL & kdltk-plugin
On Thursday 18 September 2008 16:31:20 S Roderick wrote:
>
> I believe that I might have added the lines to the ocl/config/FindKDL.cmake
> file that started this discussion. IIRC (and this is dim, it was a few
> months ago), I had to add those to deal with libraries that used KDLTK that
> were loaded/run by the deployer. The problem started with the deployer not
> loading plugins as the default directory was fixed (I have Orocos in a
> non-standard location), but it may have progressed to more than just this
> as the problem. I don't quite remember, but I strongly remember having to
> add some way to get that plugin into the runtime system to actually get the
> application to startup.
That's what I vaguely remember as well. That at that time, the plugins were
not using the RTT::Plugin interface and that linking was the only way to get
the code to work. But that's useless now. Even more, the kdltk libs are only
put in the .pc files, the OCL components/binaries are *not* linked with them.
So this is a really awkward situation. It just looks like 'dead' code to me.
>
> I believe that my situation also also negates Peter's first comment above.
> Because I have Orocos installed in a non-standard location (ie not /usr)
> then I will, by default, have components that need a plugin from a
> non-standard library path, right?
Ok. I was oversimplifying. The .pc files also work for non-/usr/lib installs
of components, but the user will set LD_LIBRARY_PATH=/opt/lib or similar.
In the current situation, he needs to set
LD_LIBRARY_PATH=/opt/lib:/opt/lib/rtt/lxrt/plugins:/opt/lib/rtt/gnulinux/plugins:...
or he will get a run-time linking error. That was not acceptable.
Peter