Bug 459830 - Anomaly: KPluginMetaData(file) uses different search path to KPluginMetaData::findPlugins()
Summary: Anomaly: KPluginMetaData(file) uses different search path to KPluginMetaData:...
Status: RESOLVED FIXED
Alias: None
Product: frameworks-kcoreaddons
Classification: Frameworks and Libraries
Component: general (other bugs)
Version First Reported In: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Alexander Lohnau
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-09-29 17:54 UTC by Jonathan Marten
Modified: 2022-10-22 17:58 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: 5.100
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Marten 2022-09-29 17:54:22 UTC
SUMMARY

KPluginMetaData::findPlugins() uses KPluginMetaDataPrivate::forEachPlugin() which prepends QCoreApplication::applicationDirPath() to the standard list of directories searched for plugins, QCoreApplication::libraryPaths().  This is obviously intended to support running uninstalled as described in https://community.kde.org/Guidelines_and_HOWTOs/Making_apps_run_uninstalled
and works.  The built but uninstalled plugins are given priority over installed plugins.

However, if a plugin is to be loaded using KPluginMetaData(const QString &file) with a relative file name, then the search path is not adjusted as above but the 'file' parameter is simply passed to QPluginLoader which uses QCoreApplication::libraryPaths() unchanged.

The effect of this is that KPluginMetaData::findPlugins() may return a plugin name which was found in the application build location, but KPluginMetaData(file), unless the 'file' is given as an absolute path, may either be unable to find the plugin (if it is not system installed) or load a different one (if it is system installed but out of date).

ADDITIONAL INFORMATION

Suggest that KPluginMetaData, when both listing and loading plugins, should use the same modified search path.  The simplest solution would be to modify QCoreApplication::libraryPaths() either at startup or temporarily, to prepend the application directory.
Comment 1 Alexander Lohnau 2022-10-13 16:57:56 UTC
I will make a MR tomorrow, locally I have a draft + test case already.
Comment 2 Bug Janitor Service 2022-10-14 18:09:55 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/265
Comment 3 Alexander Lohnau 2022-10-22 17:58:05 UTC
Git commit 4ff1f9660c634f7308a6f868fffa003b588f42e7 by Alexander Lohnau.
Committed on 22/10/2022 at 17:31.
Pushed by alex into branch 'master'.

KPluginMetaData: Check applicationDirPath first when resolving plugin paths

KPluginMetaData::findPlugins prepends this path to the library paths, but when we
load a plugin by name we did not take this path into account.
FIXED-IN: 5.100

M  +37   -0    autotests/kpluginmetadatatest.cpp
M  +15   -2    src/lib/plugin/kpluginmetadata.cpp

https://invent.kde.org/frameworks/kcoreaddons/commit/4ff1f9660c634f7308a6f868fffa003b588f42e7