Hi RTT developers,
I made some small modifications to the orocos-rtt-config.cmake script to handle the case, where RTT_COMPONENT_PATH contains multiple paths separated by colons. This syntax seems to be expected by the PluginLoader, but cmake uses semicolons as default list separator and therefore fails finding plugins and typekits.
Another minor edit resets the OROCOS-RTT_*_FOUND and OROCOS-RTT_*_LIBRARY variables on each cmake run, so that missing libraries are not accidentally reported as found.
Btw, when using the debian packages of rtt and ocl I have the problem that the symlinks from the fully versioned library files (e.g. liborocos-rtt-gnulinux.so.2.1.1) to the respective *.so files (liborocos-rtt-gnulinux.so) are not created automatically during the installation, neither for the core libraries nor for components, plugins and typekits. Without these symlinks RTT does not load the plugins during startup. I guess this problem would be solved by setting the SOVERSION property when building the libraries or alternatively by modifying the PluginLoader to also accept the versioned filenames?
Regards,
Johannes
| Attachment | Size |
|---|---|
| 0001-cmake-handle-multiple-paths-in-RTT_COMPONENT_PATH-co.patch | 1.87 KB |
[PATCH] multiple paths in RTT_COMPONENT_PATH
On Thursday 17 February 2011 17:24:25 Johannes Meyer wrote:
> Hi RTT developers,
>
> I made some small modifications to the orocos-rtt-config.cmake script to
> handle the case, where RTT_COMPONENT_PATH contains multiple paths
> separated by colons. This syntax seems to be expected by the PluginLoader,
> but cmake uses semicolons as default list separator and therefore fails
> finding plugins and typekits.
>
> Another minor edit resets the OROCOS-RTT_*_FOUND and OROCOS-RTT_*_LIBRARY
> variables on each cmake run, so that missing libraries are not
> accidentally reported as found.
Missed this one. Applied on toolchain-2.3.
>
> Btw, when using the debian packages of rtt and ocl I have the problem that
> the symlinks from the fully versioned library files (e.g.
> liborocos-rtt-gnulinux.so.2.1.1) to the respective *.so files
> (liborocos-rtt-gnulinux.so) are not created automatically during the
> installation, neither for the core libraries nor for components, plugins
> and typekits. Without these symlinks RTT does not load the plugins during
> startup. I guess this problem would be solved by setting the SOVERSION
> property when building the libraries or alternatively by modifying the
> PluginLoader to also accept the versioned filenames?
No. The plugin loader accepts only files ending in ".so" which are OR
unversioned libraries OR symlinks to versioned libraries (.so.1.2.3).
I believe what you saw in the debian packages must have been a bug in the
debian packages ? Did you install the -dev variants of the packages ? The
symlinks are packaged seperately.
Peter
[PATCH] multiple paths in RTT_COMPONENT_PATH
> On Thursday 17 February 2011 17:24:25 Johannes Meyer wrote:
> > Hi RTT developers,
> >
> > I made some small modifications to the orocos-rtt-config.cmake script to
> > handle the case, where RTT_COMPONENT_PATH contains multiple paths
> > separated by colons. This syntax seems to be expected by the PluginLoader,
> > but cmake uses semicolons as default list separator and therefore fails
> > finding plugins and typekits.
> >
> > Another minor edit resets the OROCOS-RTT_*_FOUND and OROCOS-RTT_*_LIBRARY
> > variables on each cmake run, so that missing libraries are not
> > accidentally reported as found.
>
> Missed this one. Applied on toolchain-2.3.
Thanks!
>
> >
> > Btw, when using the debian packages of rtt and ocl I have the problem that
> > the symlinks from the fully versioned library files (e.g.
> > liborocos-rtt-gnulinux.so.2.1.1) to the respective *.so files
> > (liborocos-rtt-gnulinux.so) are not created automatically during the
> > installation, neither for the core libraries nor for components, plugins
> > and typekits. Without these symlinks RTT does not load the plugins during
> > startup. I guess this problem would be solved by setting the SOVERSION
> > property when building the libraries or alternatively by modifying the
> > PluginLoader to also accept the versioned filenames?
>
> No. The plugin loader accepts only files ending in ".so" which are OR
> unversioned libraries OR symlinks to versioned libraries (.so.1.2.3).
>
> I believe what you saw in the debian packages must have been a bug in the
> debian packages ? Did you install the -dev variants of the packages ? The
> symlinks are packaged seperately.
You are right. The -dev variants also install the symlinks. This behavior is okay for the core libraries, but I would expect that the deployer or PluginLoader also do their job when only the runtime packages are installed on the robot. So IMHO for components, plugins and typekits the symlinks should be contained in the non-dev-packages or these files should be completely unversioned.
Johannes