libelektra
libelektra copied to clipboard
Build Server: CMAKE_INSTALL_PREFIX=/usr
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/ld.so.conf.d/ should fix the problem?
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
/usrrequire 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_PREFIXis actually a good thing in my opinion. We mention using it in our documentation so we should make sure it actually works.
RPATH
- Using
-Wl,-rpathis 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,-rpathin 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.
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/ld.so.conf
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
@kodebach So there is no way to avoid the -Wl,-rpath?
I am pretty sure there is a way. I just didn't look into it further yet, because it takes quite some time to test the changes on all supported systems. I also didn't think this was a priority since the configuration works for now.
Can we close this or is it worth to further investigate this issue?
I think the RPATH discussion plays a role in @robaerd's efforts to create better packages. I also think we should have at least one build job that tries to install Elektra into /usr like a package would do.
I mark this issue stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping the issue by writing a message here or create a new issue with the remainder of this issue. Thank you for your contributions :sparkling_heart:
I closed this issue now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue. Thank you for your contributions :sparkling_heart:
@markus2330 Ignoring all the RPATH discussion, do we now have a build job that installs into /usr?
We need to check if there is a make install to /usr. Probably we only use the package manager for that.
If the packages are installed and then tests are run, that would probably be good enough too.
I mark this stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping by writing a message here or create a new issue with the remainder of this issue. Thank you for your contributions :sparkling_heart:
I closed this now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue. Thank you for your contributions :sparkling_heart: