Comments (10)
Unfortunately not easily as of today. The primary reason is that Orocos creates libraries at locations below lib
, e.g. in lib/orocos/gnulinux/<package>
, and relies on compiled-in RPATH to still enable other libraries to link against them. This is especially the case for typekits.
Without changing this fundamental design of the Orocos plugin system there is no easy way to relocate an install-space because setting [DY]LD_LIBRARY_PATH
alone would not help to fix the linking problems. One possibility would be to install all libraries to the default library destination lib
and create other files (e.g. XML manifests) in the lib/orocos
subfolder to help the ComponentLoader
and PluginLoader
to find the plugin libraries that are meant to be plugins and loaded at run-time. Another possibility is to disallow linking to a component, plugin or typekit library that is not installed to a path outside [DY]LD_LIBRARY_PATH
. This would require splitting typekits into a "normal" library that contains all the explicitly instantiated templates and which gets linked to other Orocos libraryes, and a trivial typekit plugin library, which only has the plugin entry code.
We could leave this issue open as a feature request, but it will probably not be implemented soon and require quite some changes. Unless someone has a better idea how to solve it.
from rtt.
@ahoarau What do you mean by "portable"? Do you want an install that you can move to an arbitrary location(s), or do you want the simpler version where you build/install in one location and then move the install to another a priori known location? The second one is mostly supported by DESTDIR type semantics in Orocos, though some of the hard coded paths might need fixing. The first one is much more difficult due to RPATH and other considerations, let alone the hard coded paths.
from rtt.
Couldn't we make use of $ORIGIN
in the RPATH? For example a plugin installed in
${CMAKE_INSTALL_PREFIX}/lib/orocos${OROCOS_SUFFIX}/${PROJECT_NAME}/plugins
would have this kind of RPATH:
$ORIGIN/..
$ORIGIN/../types
$ORIGIN
$ORIGIN/../../..
instead of
${CMAKE_INSTALL_PREFIX}/lib/orocos${OROCOS_SUFFIX}/${PROJECT_NAME}
${CMAKE_INSTALL_PREFIX}/lib/orocos${OROCOS_SUFFIX}/${PROJECT_NAME}/types
${CMAKE_INSTALL_PREFIX}/lib/orocos${OROCOS_SUFFIX}/${PROJECT_NAME}/plugins
${CMAKE_INSTALL_PREFIX}/lib
(taken from orocos_set_install_rpath
).
from rtt.
I was not aware of $ORIGIN
yet. That could work, given that all Orocos binaries are installed to the same prefix. I cannot foresee yet how it works if some packages are already installed in a separate install-space. For example with ROS, RTT and other packages installed from binary Debian packages are located in /opt/ros/distro/lib/orocos
. User packages are then typically built and installed in an overlay (separate build- and install-space). The library paths of the underlay must still be added to the RPATH
explicitly because they cannot be found relative to $ORIGIN
.
The orocos_set_install_rpath() macro already adds all the library dirs of used dependencies (passed from ${USE_OROCOS_LIBRARY_DIRS}
via ${ARGN}
) and RTT and OCL (${OROCOS-RTT_LIBRARY_DIRS}
, ${OROCOS-OCL_LIBRARY_DIRS}
). So that could work as long as only the top-level install-space is relocated and not one of the underlays.
The absolute paths are also written to the pkg-config files generated by orocos_generate_package() and parsed by the orocos_find_package() and orocos_use_package() macros. Finding packages and libraries at build-time from a relocated install-space from only CMAKE_PREFIX_PATH
and PKG_CONFIG_PATH
should also be considered as part of the problem.
A pull request that suggest the necessary changes for further testing would be very welcome.
Wiki page about RPATH handling with CMake:
https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling
from rtt.
In all honesty I think you might need both options, to support the different use cases; 1) for system level installs or alternate install spaces, where absolute paths are required, and 2) when installing in your application install space, and then relative paths are ok.
Also, certainly on the Mac you need full path for system installed shared libraries due to lack of DYLD_LIBRARY_PATH for security reasons.
from rtt.
In 'deployer' script, if we replace:
abspath="/the/hardcoded/path"
by
abspath="$(dirname $(readlink -f $0))"
It seems to work for loading everything.
Question2: Is there a way to just install eveything in '/lib', rather than '/lib/orocos//types/' etc ?
from rtt.
For the "$ORIGIN in Rpath solution", I have a CMake function that fixes the RPATH of already compiled .so. It could also be used to fix the RPATH before the compilation.
from rtt.
It seems to work for loading everything.
- extending the RTT_COMPONENT_PATH as well.
from rtt.
Question2: Is there a way to just install eveything in '/lib', rather than '/lib/orocos//types/' etc ?
I totally agree that this would be much simpler, but unfortunately not without refactoring the ComponentLoader
and PluginLoader
(which should be unified anyway). See #303 (comment).
What was question 1? ;-)
Also, certainly on the Mac you need full path for system installed shared libraries due to lack of DYLD_LIBRARY_PATH for security reasons.
I agree with @snrkiwi that there are cases where absolute paths are required. But it is not because of DYLD_LIBRARY_PATH
on macOS. The RPATH
mechanism is exactly there to not have to depend on unsecure [DY]LD_LIBRARY_PATH
environment settings.
It seems to work for loading everything.
Using a relative RPATH
only works for packages found in the same install-space, and under the assumption that they will only be relocated together. With overlays, like in the case of Debian packages released into ROS (or if RTT is installed to /usr
), dependent packages must still have the absolute paths to all linked libraries linked from /opt/ros/xxx/lib/orocos/gnulinux/...
in their RPATH because they cannot or they will not be found relative to $ORIGIN
.
So some magic would be required in orocos_set_install_rpath() to configure the INSTALL_RPATH
depending on whether a linked library is installed in the same install-space (in ${CMAKE_INSTALL_PREFIX}) or not. This can be tricky, especially with the various options to build a catkin package. In case of
catkin_build`, with a single non-isolated build directory for the whole workspace, other package's libraries are not yet installed at the time a dependent package is built.
I'll give it a try this week, but a pull request with whatever approaches you already tested would be helpful as a starting point.
from rtt.
Nice explanation of RPATH handling and respective CMake options:
https://gitlab.kitware.com/cmake/community/-/wikis/doc/cmake/RPATH-handling
from rtt.
Related Issues (20)
- no boost / RTTv3 HOT 1
- clarification on copyright HOT 3
- 2.9.1 ros debian package fails to install HOT 5
- Massive deadlocking when disconnecting connections in parallel HOT 2
- Omniorbpy
- rtt does not support const array ?
- orocos with imcompatiable gcc version (7.4) HOT 1
- cleanupHook called twice after in runtime -> exception -> cleanup
- sample given to setDataSample seem to sometimes "leak" to the other side HOT 3
- catkin build err HOT 2
- PluginLoader::loadTypekits throws boost::filesystem_error for "File name too long" with long path_list
- Problems installing OROCOS under Linux-RTAI/Xenomai HOT 4
- Value parse problem with user defined data in a property bag
- Windows build broken
- Could not allocate configuration semaphore 'sem' for ***,Throwing std::bad_alloc. HOT 1
- Orocos on raspberrypi 3b+ HOT 4
- How to properly configure services
- Communication between OROCOS components via Ethernet network HOT 3
- Deadlock when the input event port is disconnected from the output when the connection is active
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rtt.