Installation from source leads to non-functional installation

[hboehmer868]

How to recreate:

1. Create a clean python virtualenv in an empty folder

python -m venv .env

2. Install pywhispercpp from source

pip install git+https://github.com/abdeladim-s/pywhispercpp

3. Run python interactive shell and import Model

>>> from pywhispercpp.model import Model
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.12/site-packages/pywhispercpp/model.py", line 13, in <module>
    import _pywhispercpp as pw
ImportError: libwhisper.so: cannot open shared object file: No such file or directory

I have not quite wrapped my head around the issue but it seems that when installing a python package like this pip builds the wheel in the process and the libwhisper.so file is included in the python site packages. However the site package directory is by default not included in the LD_LIBRARY_PATH.

However when i manually build the wheel after cloning the repository with python -m build --wheel . and install from the wheel file, libwhisper.so is successfuly included and found on import.

[abdeladim-s]

@hboehmer868, I just tested this out and you are right! It's weird to be honest! Pip install should behave the same in both cases!!
What do you think might be the cause of this issue ?

[hboehmer868]

@abdeladim-s I have looked into it further and narrowed down the issue and its REALLY weird. My experiment setup is something like this:

1. Create an empty virtualenv, install from github directly, import Model -> libwhisper.so is included in site-packages, import still fails with error libwhisper.so is missing
2. Create another empty virtualenv, clone repository, build wheel, install wheel, import Model -> libwhisper.so is included in site-packages, import is successful (seems to work right?)
3. WRONG, because if i delete the resulting build folder in the repository i cloned the import fails again, even though the wheel is still installed in my virtualenv.

This indicates to me that for some reason not the libwhisper.so from the installed wheel is used, but the libwhisper.so that is created in the build directory of the cloned repository. This also explains why straight installing from github does not work. There the repository is cloned in a temporary folder, the wheel is build and installed and then the temporary folder is deleted, removing the libwhisper.so that would be used.

[hboehmer868]

@abdeladim-s I am not too familiar with how the build and publish process to pypi works, but something with that is different, so that when i install a wheel from pypi the correct libwhisper.so (the one included in the wheel itself) is used.

[hboehmer868]

@abdeladim-s Okay I managed to build a truly self-contained wheel file by following the CI pipeline of this repository (good job setting that up properly). The CI pipeline uses cibuildwheel to build the wheels that get published to pypi. The docs of cibuildwheel describe which steps it goes through and this line in the docs lead me on the right track:

• Bundles shared library dependencies on Linux and macOS through auditwheel and delocate

So I did the same manually with my previously build wheel file, et voila I was given a proper self contained wheel file.
If all this can be achieved when installing directly from github, I doubt it.

[jfbvalenzuela]

Hi, just dropping by to report that compiling from source using the latest git version of whisper.cpp leads to errors due to the removal of the speed_up and phase_vocoder* functions just yesterday. The first error popping out of cmake (called by python -m build --wheel) below:

/(home_dir)/pywhispercpp/src/main.cpp:100:12: error: use of undeclared identifier 'whisper_pcm_to_mel_phase_vocoder'; did you mean 'whisper_pcm_to_mel_phase_vocoder_wrapper'?
    return whisper_pcm_to_mel_phase_vocoder(ctx->ptr, samples_ptr, n_samples, n_threads);
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           whisper_pcm_to_mel_phase_vocoder_wrapper

Manually checking out and using v1.5.4 (or any whisper.cppcommit prior to af5833e before building from the git repo with python -m build --wheel should work.

[abdeladim-s]

Thanks a lot @hboehmer868 for tracking the issue.
Indeed Python is picking the libwhisper.so inside the lib folder that's why we were not getting any errors.
Using auditwheel and delocate fixes this issue as you noticed. And that's also explains why it does not work on windows because no fix is applied by default on the cbuildwheel.
I tried to implement a hacky workaround to include libwhisper.so with the package and load it at runtime. It seems to work on my end.
Please give it a try and see if Pip install work even if you delete the build directory ?
You can also build a self contained wheel without audithweel. But I am not sure if it will work with pip install git+ yet.

[abdeladim-s]

Hi, just dropping by to report that compiling from source using the latest git version of whisper.cpp leads to errors due to the removal of the speed_up and phase_vocoder* functions just yesterday. The first error popping out of cmake (called by python -m build --wheel) below:

/(home_dir)/pywhispercpp/src/main.cpp:100:12: error: use of undeclared identifier 'whisper_pcm_to_mel_phase_vocoder'; did you mean 'whisper_pcm_to_mel_phase_vocoder_wrapper'?
    return whisper_pcm_to_mel_phase_vocoder(ctx->ptr, samples_ptr, n_samples, n_threads);
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           whisper_pcm_to_mel_phase_vocoder_wrapper

Manually checking out and using v1.5.4 (or any whisper.cppcommit prior to af5833e before building from the git repo with python -m build --wheel should work.

Hi @jfbvalenzuela,
Thanks for letting us know!

Do you mind to check what is the latest release of whisper.cpp we can safely checkout to, without breaking anything, So I can update the PYPI wheels.

[hboehmer868]

@abdeladim-s It does not seem to work for me, I am afraid.

[jfbvalenzuela]

Hi, just dropping by to report that compiling from source using the latest git version of whisper.cpp leads to errors due to the removal of the speed_up and phase_vocoder* functions just yesterday. The first error popping out of cmake (called by python -m build --wheel) below:

/(home_dir)/pywhispercpp/src/main.cpp:100:12: error: use of undeclared identifier 'whisper_pcm_to_mel_phase_vocoder'; did you mean 'whisper_pcm_to_mel_phase_vocoder_wrapper'?
    return whisper_pcm_to_mel_phase_vocoder(ctx->ptr, samples_ptr, n_samples, n_threads);
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           whisper_pcm_to_mel_phase_vocoder_wrapper

Manually checking out and using v1.5.4 (or any whisper.cppcommit prior to af5833e before building from the git repo with python -m build --wheel should work.

Hi @jfbvalenzuela, Thanks for letting us know!

Do you mind to check what is the latest release of whisper.cpp we can safely checkout to, without breaking anything, So I can update the PYPI wheels.

Hi, just dropping by to report that compiling from source using the latest git version of whisper.cpp leads to errors due to the removal of the speed_up and phase_vocoder* functions just yesterday. The first error popping out of cmake (called by python -m build --wheel) below:

/(home_dir)/pywhispercpp/src/main.cpp:100:12: error: use of undeclared identifier 'whisper_pcm_to_mel_phase_vocoder'; did you mean 'whisper_pcm_to_mel_phase_vocoder_wrapper'?
    return whisper_pcm_to_mel_phase_vocoder(ctx->ptr, samples_ptr, n_samples, n_threads);
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           whisper_pcm_to_mel_phase_vocoder_wrapper

Manually checking out and using v1.5.4 (or any whisper.cppcommit prior to af5833e before building from the git repo with python -m build --wheel should work.

Hi @jfbvalenzuela, Thanks for letting us know!

Do you mind to check what is the latest release of whisper.cpp we can safely checkout to, without breaking anything, So I can update the PYPI wheels.

Commit b87494b is the last one before the breaking change; python -m build --wheel is successful with this one (with a post-installation caveat for MacOS users wanting to use CoreML support)

Hope this helps!

[abdeladim-s]

@hboehmer868 Can you please follow this and share the output wheel in the dist folder ?

git clone --recursive https://github.com/abdeladim-s/pywhispercpp
cd pywhispercpp
git checkout eb22513c3524fe721e326665673395ad0a9d7cb7 # before the Whisper.cpp v1.6.2 update
pip install . 
pip wheel . -w dist --no-deps

[abdeladim-s]

Commit b87494b is the last one before the breaking change; python -m build --wheel is successful with this one (with a post-installation caveat for MacOS users wanting to use CoreML support)

Hope this helps!

@jfbvalenzuela, OK, I will try to update the wheels to the latest release as soon as possible.
Thank you very much!

[hboehmer868]

@hboehmer868 Can you please follow this and share the output wheel in the dist folder ?

git clone --recursive https://github.com/abdeladim-s/pywhispercpp
cd pywhispercpp
git checkout eb22513 # before the Whisper.cpp v1.6.2 update
pip install .
pip wheel . -w dist --no-deps

pywhispercpp-1.2.0-cp312-cp312-linux_x86_64.zip

These are the contents of the wheel file as a zip archive. Github does not let me upload the wheel directly. I installed this wheel file with pip install --force-reinstall pywhispercpp-1.2.0-cp312-cp312-linux_x86_64.whl. When i removed the build directory I got the libwhisper.so no such file error again.

[abdeladim-s]

@hboehmer868, it seems that the generated wheel contains the lib folder with the shared libraries, so it should be working basically.
Here I tried to replicate the same process on colab, and it seems to be working. Give it a try and let me know what you think.

[hboehmer868]

@abdeladim-s Yes in colab it seems to work, even if you forgot to actually delete the build directory inside the pywhispercpp folder. I added it and removed it and it still worked.
HOWEVER when i try it in my own freshly setup environment it still gives the libwhisper.so missing error. Now I am really struggling to understand whats going on.
Do you have any idea what I can try to narrow down the problem?
Maybe you can locally try yourself:

1. Follow the steps you asked me to try
2. Install the resulting wheel from pywhispercpp/dist/pywhispercpp-*.whl
3. Delete pywhispercpp/build folder
4. Try from pywhispercpp.model import Model

[abdeladim-s]

@hboehmer868,

@abdeladim-s Yes in colab it seems to work, even if you forgot to actually delete the build directory inside the pywhispercpp folder. I added it and removed it and it still worked.

What do you mean ? I even mentioned to delete the entire colab runtime, not just the build folder.
When you build the wheel, download it to your local system, then delete and reconnect colab (or even start a new session), next upload the wheel and install it (Do no repeat the previous steps of building the wheel)!

HOWEVER when i try it in my own freshly setup environment it still gives the libwhisper.so missing error. Now I am really struggling to understand whats going on. Do you have any idea what I can try to narrow down the problem? Maybe you can locally try yourself:

1. Follow the steps you asked me to try
2. Install the resulting wheel from pywhispercpp/dist/pywhispercpp-*.whl
3. Delete pywhispercpp/build folder
4. Try from pywhispercpp.model import Model

Yes, I already did the exact same steps before asking you to test it on your end, and it's working.

I am not really sure what might be the issue, maybe the script you are testing with is still importing the Model class from the cloned repository rather than the one installed on site-packages.
To check if this is the case, after step 2, try to create a new project with a fresh virtual environnement and install the wheel in it, create a simple test file with the import statement and see if that works!

[hboehmer868]

@abdeladim-s, apologies I misunderstood the "Download wheel + Delete Runtime + reupload wheel" line as a comment rather than an instruction.
I tried it in Colab just like you wrote and it does not work for me. Somehow you seem to have more luck with this.

[abdeladim-s]

@hboehmer868, even the Colab file I sent didn't work for you ? That's weird!
In that case maybe I am doing something wrong!
Well, let's leave this open. Hopefully, someone else will step up and give it another test.