[Bug] Linux: whisper.cpp fails with "error while loading shared libraries: libwhisper.so.1: cannot open shared object file"

[keremyavuz]

*I encountered a issue while I was trying to use speech to text function in Subtitle Edit. I use EndavourOS. I solved the problem by using AI. Having resolved the issue, I also wanted to create a ticket to let the developers know the issue. Here is the explanation of AI. Thank you.

### Environment
- **OS:** Linux (Arch Linux / EndeavourOS x86_64)
- **Subtitle Edit Version:** 5.1.0 (or latest)
- **Engine:** whisper.cpp (Speech-to-Text)

### Description
When running speech-to-text via **whisper.cpp** on Linux, the process fails immediately on launch with a missing shared library error.

### Error Log
```text
Calling speech-to-text (CPP) with : /home/user/.config/Subtitle Edit/SpeechToText/Cpp/whisper-cli --language en --model "/home/user/.config/Subtitle Edit/SpeechToText/Cpp/Models/tiny.en.bin" --output-srt --print-progress  "/tmp/se-stt-xxx/sample.wav"
/home/user/.config/Subtitle Edit/SpeechToText/Cpp/whisper-cli: error while loading shared libraries: libwhisper.so.1: cannot open shared object file: No such file or directory
Speech to text (CPP) done in 00:00:00.0961585

Running ldd on whisper-cli confirms missing dependencies:

$ ldd ~/.config/Subtitle\ Edit/SpeechToText/Cpp/whisper-cli | grep "not found"
    libwhisper.so.1 => not found
    libggml.so.0 => not found

Root Cause Analysis
Missing Shared Library: The automated download/extraction for the Linux whisper.cpp bundle in ~/.config/Subtitle Edit/SpeechToText/Cpp/ contains libggml*.so files, but libwhisper.so (or libwhisper.so.1) is missing entirely from the directory.

Missing ABI Symlinks: The binary specifically links against versioned SONAMEs (libwhisper.so.1, libggml.so.0). If only unversioned .so files exist, the dynamic linker (ld.so) fails to resolve them.

Missing RPATH / $ORIGIN: The provided whisper-cli binary does not have its RPATH / RUNPATH set to $ORIGIN. As a result, Linux does not search the local executable directory for bundled .so files unless LD_LIBRARY_PATH is explicitly exported.

Workaround Applied
Building whisper.cpp from source and updating the binary's RPATH resolves the issue completely:

TARGET="$HOME/.config/Subtitle Edit/SpeechToText/Cpp"

# Copy built shared libraries
cp -f build/bin/*.so* "$TARGET/"

# Create version symlinks
cd "$TARGET"
ln -sf libwhisper.so libwhisper.so.1
ln -sf libggml.so libggml.so.0

# Set RPATH so whisper-cli looks in its own folder for .so files
patchelf --set-rpath '$ORIGIN' whisper-cli

Suggested Fix
To make whisper.cpp work out of the box on Linux:

Ensure the downloaded zip/archive includes libwhisper.so alongside the libggml files (including the versioned symlink libwhisper.so.1).

Either:

Build the distributed whisper-cli binary with -DCMAKE_INSTALL_RPATH='$ORIGIN' (or patch it with patchelf --set-rpath '$ORIGIN'), OR

In Subtitle Edit's process execution code, prepend the directory to LD_LIBRARY_PATH when spawning whisper-cli:
process.StartInfo.EnvironmentVariables["LD_LIBRARY_PATH"] = cppFolder + ":" + Environment.GetEnvironmentVariable("LD_LIBRARY_PATH");

[niksedk]

Thanks for the detailed report — your diagnosis was correct, and it turned out to be worse than the missing libwhisper.so alone. Fixed in #13689.

What was wrong. The Linux archives are built by a workflow in our support-files repo, and its packaging step was:

cp build/bin/libggml*.so staging/

Three problems in one line:

1. The glob never matched libwhisper.so*, so — exactly as you found — it was absent from the zip entirely.
2. cp dereferences cmake's libggml.so -> libggml.so.0 -> libggml.so.0.9.4 symlink chain, so each library was packaged under its unversioned name while its SONAME (and whisper-cli's DT_NEEDED) said libggml.so.0. The loader looks libraries up by SONAME, so libggml.so could never satisfy libggml.so.0.
3. RUNPATH was left pointing at the CI build directory (/home/runner/work/...), which of course doesn't exist on your machine — your patchelf --set-rpath '$ORIGIN' was the right call.

v1.8.3 and earlier shipped a statically linked whisper-cli, which is why nobody hit this until the build switched to shared libraries. Every Linux build from v1.8.4 through v1.9.1 is affected.

The fix. The archives are rebuilt and republished (same whisper.cpp v1.9.1) with every library packaged as a real file under its SONAME and $ORIGIN RPATHs on all of them — essentially your workaround, done at build time. The build now also verifies it: it copies the payload elsewhere, runs the loader from an unrelated directory with LD_LIBRARY_PATH cleared, and fails if any bundled library doesn't resolve. That check is what was missing — the build machine had the libraries sitting in build/bin the whole time, so nothing ever noticed.

On the Subtitle Edit side the engine folder now also goes on LD_LIBRARY_PATH at launch, and the misleading "Install it with your package manager" message is gone for engine-bundled libraries — no distro ships libwhisper, so that advice was a dead end.

To pick it up, once a build with this change is out: because you patched the folder by hand, don't just re-download over the top — your self-built libggml-cpu-*.so files would linger and could get loaded alongside the new ones with a mismatched ggml ABI. Delete everything in

~/.config/Subtitle Edit/SpeechToText/Cpp/

except the Models/ subfolder (that keeps your downloaded models), then re-download the engine from the speech-to-text window. Anyone who didn't hand-patch anything will simply be prompted to update.

Thanks again — the ldd output and the RPATH analysis in your report are what made this quick to pin down.