New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build Server: CMAKE_INSTALL_PREFIX=/usr #2358

markus2330 opened this Issue Feb 1, 2019 · 2 comments


None yet
2 participants
Copy link

markus2330 commented Feb 1, 2019

As found during #2350, it seems like we use non-standard installation paths.

Is there no way to use a standard CMAKE_INSTALL_PREFIX and avoid the -Wl,-rpath in the examples? If we cannot use CMAKE_INSTALL_PREFIX=/usr, an entry in /etc/ should fix the problem?

@markus2330 markus2330 added this to the 0.8.26 milestone Feb 1, 2019


This comment has been minimized.

Copy link

kodebach commented Feb 1, 2019

Current configuration

  • Cirrus CI jobs use the default CMAKE_INSTALL_PREFIX=/usr/local
  • Travis CI Linux jobs use a local folder inside the build directory
  • Travis CI macOS jobs use the default
  • Jenkins builds use a local folder inside the Workspace
  • I don't think every build/job does install Elektra

(@sanssecours, @ingwinlu please correct me, if am wrong)

Things to consider

  • Normally directories below /usr require root permission
  • Travis and Cirrus support sudo (at least on some of the supported OSs)
  • Jenkins uses docker therefore sudo may be problematic
  • Having one or more build jobs with a custom CMAKE_INSTALL_PREFIX is actually a good thing in my opinion. We mention using it in our documentation so we should make sure it actually works.


  • Using -Wl,-rpath is only problematic, when the executable should be portable and may be used on a system with a different configuration. That is why CMake uses it by default when building and directly executing applications, but strips it for the install step.
  • It should be fine to use -Wl,-rpath in our example. The README mentions the problems and, if you actually want to build an application for distribution you would customize the Makefile anyway. You would probably also already know about the problems with RPATH.
  • The one problem that remains, is that we actually force CMake to use RPATH in all of our builds, even for installing. The CMake documentation suggests a different approach.
  • The question at the basis of all this is: Should Elektra be a fully relocatable package or not? In my opinion we should try to be fully relocatable, if possible. Not least, because it can make testing Elektra easier.

This comment has been minimized.

Copy link
Contributor Author

markus2330 commented Feb 1, 2019

Yes, Elektra should be a fully relocatable package.

Currently, this can be easily done by setting TARGET_PLUGIN_FOLDER to an empty string or by adding the plugin folder to /etc/

The rpath solution could be fixed (to be relocatable) by using $ORIGIN (something similar is also available for Mac OS X). rpath has the advantage that Elektra's plugins do not pollute the standard library paths. But rpath is not always available or discouraged by some distributions. See also #1275

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment