Summary: | unversioned plugins library (rpmlint invalid-soname issue) | ||
---|---|---|---|
Product: | [Applications] trojita | Reporter: | kavol <kavol> |
Component: | Core | Assignee: | Trojita default assignee <trojita-bugs> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | 0.4.1 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
kavol
2014-03-25 11:58:00 UTC
Library libtrojita_plugins.so provides interfaces for trojita plugins. Every trojita plugin (and trojita executable) must be linked with that libary. And now only plugins inside trojita tree can be compiled and used (due to need for headers inside tree). So in my opinion there is no need to make this library public. But maybe we can make stable interfaces and provide public header files for plugins outside trojita tree... Reason why this library is shared is due to linking problems. Without hacks it is not possible to correctly build and link (c++) trojita executable (which can load plugins at runtime) and trojita plugins. If you want to disable building this shared libary you can disable trojita plugin support via cmake option at compile time. On top of what Pali said, I would like to stress out that this is a private library with no ABI/API guarantees -- "private" in sense that "if anything but stuff provided by Trojita links against this, things will break". What is the suggested location for such libraries? I'll be happy to adjust the build system properly as long as it does not involve too much deep magic and ugly cmake hacks. (In reply to comment #2) > On top of what Pali said, I would like to stress out that this is a private > library with no ABI/API guarantees -- "private" in sense that "if anything > but stuff provided by Trojita links against this, things will break". ok, so moving that out of ld paths was a good step ... > What is the suggested location for such libraries? I'll be happy to adjust > the build system properly as long as it does not involve too much deep magic > and ugly cmake hacks. I'm not sure if this is accepted universally, but Fedora guidelines suggest a subdirectory of lib, i.e. the abovementioned %{_libdir}/%{name} which translates to /usr/lib/trojita or /usr/lib64/trojita ... taking a quick look at directory structure in my Gentoo install, it seems it does the same Seems that this is actually OK to use unversioned .so files like this, at least according to Fedora's policies, as indicated in the other bug. *** This bug has been marked as a duplicate of bug 344537 *** |