It seems that the logic for loading tesseract may not be robust enough.

In case there's someone who can figure out a fix before me, here's some info about the relevant code.
In spectacle/src/TesseractRuntimeLoader.cpp, TesseractRuntimeLoader::loadLocked() calls TesseractRuntimeLoader::candidateLibraryNames() to get a list of library names.

>QStringList TesseractRuntimeLoader::candidateLibraryNames() const
>{
>    return {QStringLiteral("libtesseract.so.5"), QStringLiteral("libtesseract.so.4"), QStringLiteral("libtesseract.so")};
>}

In TesseractRuntimeLoader::loadLocked(), "m_library" is an instance of QLibrary (https://doc.qt.io/qt-6/qlibrary.html).

>bool TesseractRuntimeLoader::loadLocked()
>{
>    const auto candidates = candidateLibraryNames();
>    for (const QString &candidate : candidates) {
>        m_library.setFileName(candidate);
>        m_library.setLoadHints(QLibrary::ExportExternalSymbolsHint | QLibrary::PreventUnloadHint);
>
>        if (!m_library.load()) {
>            qCWarning(SPECTACLE_LOG) << "Unable to load Tesseract candidate" << candidate << ':' << m_library.errorString();
>            continue;
>        }
>
>        qCInfo(SPECTACLE_LOG) << "Attempting to use Tesseract library" << candidate;
>
>        if (!resolveSymbols()) {
>            m_library.unload();
>            continue;
>        }
>
>        if (!validateLoadedVersion()) {
>            m_library.unload();
>            continue;
>        }
>
>        m_loaded = true;
>        qCInfo(SPECTACLE_LOG) << "Loaded Tesseract runtime library from" << m_library.fileName();
>        return true;
>    }
>
>    qCWarning(SPECTACLE_LOG) << "Unable to locate a suitable Tesseract shared library";
>    return false;
>}

A possibly relevant merge request was started @ https://invent.kde.org/plasma/spectacle/-/merge_requests/511

in the meantime, doing this helps:

cd /usr/lib64
ln -s libtesseract.so.5.5 libtesseract.so.5

*** Bug 516203 has been marked as a duplicate of this bug. ***

(In reply to slartibart70 from comment #3)
> in the meantime, doing this helps:
> 
> cd /usr/lib64
> ln -s libtesseract.so.5.5 libtesseract.so.5

This worked for me. Thanks.

Git commit 921620e5153b2eb103c1633fee3995b187bd08db by Noah Davis.
Committed on 05/03/2026 at 15:07.
Pushed by ndavis into branch 'master'.

Fix tesseract not being found on Fedora

Now it tries to match any library called "tesseract"

See https://doc.qt.io/qt-6/qlibrary.html#details for how this should work.
FIXED-IN: 6.6.1

M  +5    -1    src/TesseractRuntimeLoader.cpp

https://invent.kde.org/plasma/spectacle/-/commit/921620e5153b2eb103c1633fee3995b187bd08db

Git commit 89538f014de81ce15f70a3e8b1125648ef5d37ef by Noah Davis.
Committed on 05/03/2026 at 17:54.
Pushed by ndavis into branch 'Plasma/6.6'.

Fix tesseract not being found on Fedora

Now it tries to match any library called "tesseract"

See https://doc.qt.io/qt-6/qlibrary.html#details for how this should work.
FIXED-IN: 6.6.1


(cherry picked from commit 921620e5153b2eb103c1633fee3995b187bd08db)

Co-authored-by: Noah Davis <noahadvs@gmail.com>

M  +5    -1    src/TesseractRuntimeLoader.cpp

https://invent.kde.org/plasma/spectacle/-/commit/89538f014de81ce15f70a3e8b1125648ef5d37ef

Changed the fixed-in version to 6.6.3 because the patch missed 6.6.1 and 6.6.2, but I forgot to change the commit message

This isn't working correctly in spectacle 6.6.3-1 on Fedora 43.

On a system which has the 'tesseract-libs' package installed (and therefore has library files at '/usr/lib64/libtesseract.so.5.5.2' and '/usr/lib64/libtesseract.so.5.5', but no file simply called 'libtesseract.so'), Spectacle reports that OCR is not available. Starting Spectacle from the command line gives the messages:

```
spectacle: Unable to load Tesseract candidate "tesseract" : "Cannot load library tesseract: tesseract: cannot open shared object file: No such file or directory"
spectacle: Unable to locate a suitable Tesseract shared library
spectacle: Tesseract runtime library not available
```

Looking at the documentation of the QLibrary class, does it actually do what we need here, i.e. to find 'libtesseract.so.5.5" or 'libtesseract.5.5.2.so'?

According to the docs, it "tries the name with different platform-specific file prefixes, like "lib" on Unix and Mac ... and suffixes, like ".so" on Unix...".

So, if you tell it to look for 'tesseract', you'd expect it to find 'libtesseract.so', but there's nothing to say that it will find files with version-specific suffices like 'libtesseract.so.5.5"

Can confirm:

spectacle: Unable to load Tesseract candidate "tesseract" : "Cannot load library tesseract: tesseract: cannot open shared object file: No such file or directory"
spectacle: Unable to locate a suitable Tesseract shared library
spectacle: Tesseract runtime library not available

+1. I have a live opensuse tumbleweed image with 6.6.0 and another with 6.6.3. Installing libtesseract and a language pack will get it working on 6.6.0, the exact same tesseract packages installed on the image with 6.6.3 fails as described above. I also had it working on the host prior to the update to 6.6.3 and it is no longer working there.

Probable dupes, which were added since 6.6.3:
https://bugs.kde.org/show_bug.cgi?id=518039
https://bugs.kde.org/show_bug.cgi?id=517900

(In reply to pg_tips from comment #9)
> Looking at the documentation of the QLibrary class, does it actually do what
> we need here, i.e. to find 'libtesseract.so.5.5" or 'libtesseract.5.5.2.so'?

Seems you're right. Qt is testing the 'lib' prefix, and does test the .so suffix, but does not provide any wildcard/glob searching of the name or the extension.

I have /usr/lib64/libtesseract.so.5 -> libtesseract.so.5.0.5

If I do sudo ln -s  /usr/lib64/libtesseract.so.5.0.5  %FILENAME

/usr/lib64/libtesseract.so    works
/usr/lib64/tesseract.so    works
/usr/lib64/tesseract.so.5    fails
/usr/lib64/tesseract5.so    fails

And here's our root cause, a 7 year old bug in tesseract: https://github.com/tesseract-ocr/tesseract/issues/2749#issuecomment-4148915185

It is now working for me.

Spectacle: 6.6.3
KDE Frameworks: 6.24.0
Qt: Using 6.10.2 and built against 6.10.2
Fedora Linux 43 (KDE Plasma Desktop Edition) (Wayland)
Build ABI: x86_64-little_endian-lp64
Kernel: linux 6.19.9-200.fc43.x86_64

(In reply to Nicolas Vaughan from comment #14)
> It is now working for me.
> 
> Spectacle: 6.6.3

Is that version 6.6.3-2 of the spectacle package? That has a patch by the Fedora maintainers to work around the bug.

Yes:
spectacle.x86_64 1:6.6.3-2.fc43
(In reply to pg_tips from comment #15)
> (In reply to Nicolas Vaughan from comment #14)
> > It is now working for me.
> > 
> > Spectacle: 6.6.3
> 
> Is that version 6.6.3-2 of the spectacle package? That has a patch by the
> Fedora maintainers to work around the bug.

Yes: spectacle.x86_64 1:6.6.3-2.fc43

Confirm on opensuse leap 16

spectacle: Unable to load Tesseract candidate "tesseract" : "Impossible de charger la bibliothèque tesseract : tesseract: cannot open shared object file: No such file or directory"
spectacle: Unable to locate a suitable Tesseract shared library
spectacle: Tesseract runtime library not available

Operating System: openSUSE Leap 16.0
KDE Plasma Version: 6.6.3
KDE Frameworks Version: 6.24.0
Qt Version: 6.10.2
Kernel Version: 6.12.0-160000.27-default (64-bit)
Graphics Platform: Wayland
Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz
Memory: 16 Gio of RAM (15.4 Gio usable)
Graphics Processor: Intel® Iris® Xe Graphics
Manufacturer: Notebook
Product Name: NLx0MU

Can also confirm in Kubuntu 26.04.

Same issue. Cannot find or load the versioned libraries

(In reply to Rik Mills from comment #18)
> Can also confirm in Kubuntu 26.04.
> 
> Same issue. Cannot find or load the versioned libraries

i.e. In Ubuntu cannot not find/load libtesseract.so.5 or libtesseract.so.5.0.5

Apparently a summary of my above posts and the attached links, is in order, so...

There is no need for "works for me" or "doesn't work here" posts. The nature of the problem is well understood, and we already know where it does and does not work.


There are three bugs interacting here:
- Tesseract built with cmake (fedora) has the wrong library soname (and so, mis-named symlink to the library) 
- Tesseract built with autotools (debian, suse, arch) has the wrong library filename
- Spectacle searches for the wrong name (because there is no right name, because of the above bugs)

The fix will be to first fix library naming of tesseract in each build system, and then to fix spectacle to search for the resulting libraries. 


Alternatively, for a permanent workaround if tesseract will not be fixed, spectacle could search for the various possible library names for all distros. The most portable way of doing this is 

return {QStringLiteral("tesseract.so.5.5"), QStringLiteral("tesseract.so.5"), QStringLiteral("tesseract.so.4"), QStringLiteral("tesseract")};

This will work across all distros and all compatible releases of tesseract from either build system. 

For KDE I would recommend this course forward, as it will work both immediately and after tesseract is fixed and that fix rolls out, which may take some time, may be out of sync with KDE, or may never happen at all.

@KDE: This is what happens when developers ignore legit bug reports because they don't like the user who reported the bug.

(In reply to Noah Davis from comment #6)
> Git commit 921620e5153b2eb103c1633fee3995b187bd08db by Noah Davis.

K/Ubuntu have had to revert this commit in packaging to fix this bug.

Git commit 13b0be099e7abe9bbb17b90e62c2e83afb248db7 by Nicolas Fella.
Committed on 16/04/2026 at 09:35.
Pushed by nicolasfella into branch 'master'.

Properly link against tesseract

When using QLibrary to load a library at runtime, QLibrary finds the library by
looking for a file that has a platform dependent prefix and suffix added to a
given base name (e.g., "tesseract" -> "libtesseract.so"). If a Linux distro
doesn't have a file called "libtesseract.so", the library won't be found even if
"libtesseract.so.5" exists unless you add logic to also check for that file.

Tesseract has a bug where different ways of building it can generate different
library file names (https://github.com/tesseract-ocr/tesseract/issues/2749).
We could work around this by checking the file names used by different distros,
but we've decided that it's better to link to the tesseract library to avoid
this problem entirely.

We generally prefer requiring libraries anyway to avoid situations where users
don't see a feature because they didn't know they needed to install an optional
dependency. That situation is unfortunately still not 100% avoidable since
Tesseract language packs are optional and Tesseract doesn't work without them.

M  +3    -0    CMakeLists.txt
M  +1    -1    src/CMakeLists.txt
M  +36   -67   src/OcrManager.cpp
M  +4    -5    src/OcrManager.h
D  +0    -189  src/TesseractRuntimeLoader.cpp
D  +0    -76   src/TesseractRuntimeLoader.h

https://invent.kde.org/plasma/spectacle/-/commit/13b0be099e7abe9bbb17b90e62c2e83afb248db7