libelektra icon indicating copy to clipboard operation
libelektra copied to clipboard

Build Server: CMAKE_INSTALL_PREFIX=/usr

Open markus2330 opened this issue 6 years ago • 12 comments

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?

markus2330 avatar Feb 01 '19 11:02 markus2330

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.

RPATH

  • 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.

kodebach avatar Feb 01 '19 12:02 kodebach

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

markus2330 avatar Feb 01 '19 15:02 markus2330

@kodebach So there is no way to avoid the -Wl,-rpath?

markus2330 avatar Feb 25 '19 18:02 markus2330

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.

kodebach avatar Feb 25 '19 20:02 kodebach

Can we close this or is it worth to further investigate this issue?

markus2330 avatar Dec 06 '20 10:12 markus2330

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.

kodebach avatar Dec 06 '20 12:12 kodebach

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:

stale[bot] avatar Jul 30 '22 20:07 stale[bot]

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:

stale[bot] avatar Sep 28 '22 03:09 stale[bot]

@markus2330 Ignoring all the RPATH discussion, do we now have a build job that installs into /usr?

kodebach avatar Sep 28 '22 09:09 kodebach

We need to check if there is a make install to /usr. Probably we only use the package manager for that.

markus2330 avatar Oct 08 '22 09:10 markus2330

If the packages are installed and then tests are run, that would probably be good enough too.

kodebach avatar Oct 08 '22 10:10 kodebach

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:

github-actions[bot] avatar Feb 18 '24 01:02 github-actions[bot]

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:

github-actions[bot] avatar Mar 04 '24 01:03 github-actions[bot]