-
Notifications
You must be signed in to change notification settings - Fork 123
kdb fail to open backed (dlopen) libelektra-resolver.so, but is installed in /usr/lib/elektra instead of /usr/lib #1233
Comments
Thank you for reporting the issue! Did you execute Is libelektra-resolver.so a valid symlink? Can you please check the RPATH (using Any specific reason why you added Btw. if you really want to have no RPATH, you can use Elektra without RPATH, but then you need to set |
because RPATH is a possible security hole, and point to wrong path if exist the original build path like
removing
libelektra-resolver.so is a valid symlink.
ldconfig is run automagic after update/install package (elecktra is builded through distro package manager) EDIT: merry chrismas! greetings |
Is it prohibited to use RPATH in your distribution?
np, thanks for opening the issue! Now we can improve and make better warnings if CMAKE_SKIP_INSTALL_RPATH is set and in the COMPILING docu. Merry christmas! |
not prohibited, but yes recomended |
In 5b3cfb1 I added some notes about RPATH in the docu, does it cover everything you need?
Is this also the case for private libraries or plugins? Usually exactly the use case of Elektra is an exception. I added the pro/cons of RPATH in doc/COMPILE.md. The major advantage of not using RPATH (relocatable binaries) unfortunately is currently not supported by Elektra for another reason (TARGET_TOOL_EXEC_FOLDER is hardcoded at some places). Are relocatable binaries important for you?
Thanks, this is a good catch! But this is an unrelated problem which is not fixed by |
the problem is the RPATH points to build folder instead of prefix path. the RPATH should be point to CMAKE_INSTALL_PREFIX |
Yes, there should be no RPATH in elektra-qt-editor at all, the installation routine was wrong.
Yes, in installed Elektra by default there is only one RPATH which points to the plugin folder, which is a subdirectory of CMAKE_INSTALL_PREFIX. Is now everything documented properly in doc/COMPILE.md? Or simply close the issue if you think no further discussion is needed. |
yes. all is ok grettings (and sorry again) |
We have to thank you, you found an important issue. Please never hesitate to open an issue, we love feedback ❤️ |
RPATH is a serious problem in openSUSE. The current rpm's do not work :-P The oS RPM manual states RPATH is forbidden in Fedora (not checked). Please consider a solution for searching the plugins. Easy would be to scan all LD_LIBRARY_PATH contained paths and add the TARGET_PLUGIN_FOLDER sub directory to the full path name. Additional the CMAKE_INSTALL_LIBDIR/TARGET_PLUGIN_FOLDER would be good I guess. In Oyranos, we use the runtime LD_LIBRARY_PATH + OY_MODULE_PATH environment variables in order to allow relocatable applications like OS X app bundles. Additionally and first the static (compile time) OY_LIBDIR/OY_CMMSUBPATH OY_USER_PATH/OY_CMMSUBPATH paths are always scanned. And Oyranos modules have a version inside, which is checked after dlopen() time for avoiding conflicts caused by outdated module API's. |
For "ICC Examin.app" we use a load script and need to specify The unfortunate situation is, all applications, which link against elektra and oyranos need to set the according variables. That's not intuitive ATM. |
@beku The solution is simple and supported since some releases: Simply use Alternatively, you could add the plugin folder in The tradeoffs are discussed here.
Exactly! Thus we want to avoid to use any environment variables, they bring inconsistent KDB behavior depending on how they are set, which is against Elektra's goal to unify configuration. We discuss the tradeoff usability vs. unified access here: #1249 I recommend you to use KDB to get the variables/paths and avoid wrapper scripts/environment variables. |
Thanks for pointing out. Reducing dependence on environment variables is well explained and understandable for elektra. As a consequence of installing plugins into the main ldconfig paths, could elektra link it's modules into bigger libraries sorted by their dependencies? That way they can still be separately packaged without cluttering the lib paths. E.g.: |
Thanks for the suggestion, we will discuss it! (it would be a solution between the full build and being completely modular: faster, but still good package-able) But if your concern is only the cluttering of the libs directory, why not using the solution with What is your opinion about using RPATH by default? Thus it does not work on more and more distros ... (though nobody could explain to me why they are turning it off, it is quite clear that RPATH has its use cases, e.g., for private libs) |
Can elektra provide /etc/ld.so.conf.d/elektra by default in case of -DTARGET_PLUGIN_FOLDER="" ? |
Currently not, we can discuss it. So you mean, when Alternatively we could set
|
Oops. The other way round. With TARGET_PLUGIN_FOLDER != "", create a /etc/ld.so.conf.d/elektra.conf file with the system module path. |
Ok, thanks for your feedback! We will definitely do something till next release, I started the discussion in #1275. We would love to hear what is your favorite way! |
open kdb without arguments
but the file exist in /usr/lib/elecktra
builded with:
The text was updated successfully, but these errors were encountered: