Alternatives for RPATH

[markus2330]

Thus in some modern distros RPATH fails both in build-tree (#1255) and after installation (#1233) we should reconsider the default, or at least use a different method when -DCMAKE_SKIP_INSTALL_RPATH=ON is set. We have following possibilities:

1. do nothing, keep RPATH as default, when compiling Elektra on a problematic distro, the maintainer needs to set -DTARGET_PLUGIN_FOLDER=""
2. hardcode paths when loading plugins, have some way for users to add plugins.
3. installing /etc/ld.so.conf.d/elektra.conf with whatever was set as plugin path (wont work when INSTALL_SYSTEM_FILES is off)
4. use RUNPATH instead (does not work on openwrt, to investigate if it works on all problematic distros. It is, however, less suited for our needs: using different plugins can be configured with kdb mount, thus there is no need to honor LD_LIBRARY_PATH)
5. switch to -DTARGET_PLUGIN_FOLDER="" as default, maybe together with @beku recommendation to group plugins according to their dependency.
6. specify a tool to obtain valid lookup paths for external plugin installation.

We should consider:

• works everywhere without issues (the most important one 😄)
• if Elektra is relocatable (only TARGET_PLUGIN_FOLDER as empty is, or when using $ORIGIN in RPATH or RUNPATH)
• works with every program (e.g. setuid binaries and so on, all of the above would work, only when using $ORIGIN we would get into troubles, at least the ELF specification recommends to ignore $ORIGIN in that case)
• also works for non-installed versions (see KDB Does Not List YAJL Plugin #1612)

[beku]

2. +1 hardcoding paths with -DTARGET_PLUGIN_FOLDER != "" + a way to detect valid system and user plugin paths.
3. -1 is a special platform thing (step learning curve)
5. looks promising. It can filter valid libelektra-* plugins out of many libraries in the system and should not have a big impact on load time.
6. specify a tool to obtain valid lookup paths for external plugin installation. Document in https://www.libelektra.org/plugins/readme

Here some applications running widely used plugin systems since quite some time:
http://www.audacityteam.org/download/plug-ins/
https://en.wikibooks.org/wiki/GIMP/Installing_Plugins/

[markus2330]

Thanks for your feedback, extending 2., and suggesting 6.
I added it above!

[markus2330]

In #2593 the problem appeared again. I would be in favor of using option 5. for the upcoming release. Maintainers can then still use -DTARGET_PLUGIN_FOLDER="elektra" to restore the old behavior.

[sanssecours]

Using the second option for Linux and FreeBSD makes sense. I think we should keep RPATH as default option on macOS though.

[markus2330]

I also think that the RPATH solution is more clean (separate libraries and plugins) but it seems the general trend goes in a different direction.

It would avoid problems like #2321 and #1233 and if someone wants the separation, it is easy to add -DTARGET_PLUGIN_FOLDER="elektra".

[sanssecours]

It would avoid problems like #2321 and #1233 and if someone wants the separation, it is easy to add -DTARGET_PLUGIN_FOLDER="elektra".

None of those issues mention macOS. I think some simple if-statements in the CMake code:

if (UNIX)
  if (APPLE)
    # Use `RPATH` on macOS
  else (APPLE)
    # Use something different for Linux & FreeBSD
  endif (APPLE)
endif (UNIX)

should be enough to handle the different options.

[markus2330]

I'll also use the TARGET_PLUGIN_FOLDER for Debian. But I think this is more my personal preference and not something specific to Debian. Don't you think it is the same for macOS? (That it is your preference and not specific to macOS?)

[markus2330]

Btw. furthermore it is possible that macOS (or Debian) will drop their support for RPATH. Then it is better that the maintainer used TARGET_PLUGIN_FOLDER on purpose (and will be aware of potential regressions in future.)

[sanssecours]

Don't you think it is the same for macOS? (That it is your preference and not specific to macOS?)

I am certainly not an expert about this stuff, but as far as I know, using RPATH is the preferred way to keep libraries relocatable on macOS since a decade.

Btw. furthermore it is possible that macOS (or Debian) will drop their support for RPATH.

I did not hear anything about Apple dropping RPATH support for macOS.

[markus2330]

At the moment, however, our RPATH solution is not relocatable as we do not use @rpath (MacOS), $ORIGIN (glibc) or similar.

So if we keep RPATH as default, we should also fix this.

[stale]

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 💖

[stale]

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 💖