Instead of assuming the unversioned .so symlink will exist also at
runtime (which is not the case for binary distros), use the QLibrary
features: the SONAME of the Python library is "1.0", so use the
unsuffixed filename of Python library with it.
Additionally, this extends the loading also to Unices platforms
different than macOS (since Boud excluded it in a previous commit),
and destroy the QLibrary in case of loading failure.
BUG: 393307
Fixed-In: 4.0.4
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
Um... This only applies to the krita/4.0, doesn't it? And doesn't removing the else block break the case where the library isn't anymore in the location where cmake found it?
This only applies to the krita/4.0, doesn't it?
Ahh yes... I thought fixes would be to stable branches, and then merged to master. I can rebase it to master in the next version.
And doesn't removing the else block break the case where the library isn't anymore in the location where cmake found it?
If the library name is a simple file name (i.e. not a full path), QLibrary does a search in the library paths. This was the case I wanted to fix, i.e. libpythonX.Yetc.so present at build time (and stored in the PYKRITA_PYTHON_LIBRARY define), but not present at runtime (where only the libpythonX.Yetc.so.1.0 is available); this is typically the case of binary distros that split library/devel stuff, such as Debian, Fedora, *SUSE, and their derived.
We usually go from master to the stable branch, which I know isn't the recommended flow, but it's what we do... I guess that this patch should be fine then, because the appimage sets the library paths. It might even fix loading python in a macOS app bundle, because that had the same problems as the appimage.