MSVC C++ runtime (msvcp140.dll) version conflict

[damonlynch]

This will segfault on Windows, because PyQt5 pulls in PyQt5\Qt5\bin\msvcp140.dll (version 14.26.28720.3) which is too old for exiv2:

import PyQt5.QtCore
import exiv2


path = r"path\to\photo.jpg"

print(PyQt5.QtCore.PYQT_VERSION_STR)

image = exiv2.ImageFactory.open(path)
image.readMetadata()
exif_data = image.exifData()
print(exif_data["Exif.Photo.FNumber"])

Swapping the import order so that exiv2 is imported before PyQt5 fixes the segfault: exiv2 uses the system msvcp140.dll, and perhaps PyQt5 runs okay with that DLL version too (I am unsure — it might be fine).

Not every photo file will result in a crash when PyQt5 is imported first. Some do not. It might be that whether the crash occurs depends on the code path taken within exiv2, but I'm speculating here. I've noticed that files produced by old cameras do not crash, but those produced by newer camera always crash.

Given Qt5 is now EOL, this may not matter to python-exiv2. I'm unsure if it can be replicated with PyQt6 (I need to test that). I am slowly porting Rapid Photo Downloader to use PyQt6. I am also laying the groundwork for Rapid Photo Downloader to work on Windows in addition to Linux, which is why I have been hit with this problem.

But even if this is not a problem to fix, I think it would be nice to have it documented. It might save somebody else some time.

[jim-easterbrook]

Welcome to DLL hell. Another question is which Windows version?

My Photini project also uses PyQt and python-exiv2, but I don't think I've seen this problem. (It appears that Photini has always imported exiv2 first.) I only have Windows 7, which can't use Qt6 (PyQt6 or PySide6).

If you, or anyone else, can tell me how to change my compilation of exiv2 on Windows to prevent the problem then I'd be very grateful. I'm not a Windows programmer.

Windows build action is here:

python-exiv2/.github/workflows/build-exiv2-wheels.yml

Line 77 in ada2236

- name: Build exiv2 (Windows)

[jim-easterbrook]

Importing PyQt5 changes PATH:

(photini) C:\Users\Jim>python
Python 3.8.10 (tags/v3.8.10:3d8993a, May  3 2021, 11:48:03) [MSC v.1928 64 bit (
AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> print(os.environ['PATH'])
C:\Users\Jim\photini\Scripts;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Git\cmd;C:\Program Files\CMake\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Git\cmd;C:\Program Files\CMake\bin
>>> import PyQt5.QtCore
>>> print(os.environ['PATH'])
C:\Users\Jim\photini\lib\site-packages\PyQt5\Qt5\bin;C:\Users\Jim\photini\Scripts;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Git\cmd;C:\Program Files\CMake\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Git\cmd;C:\Program Files\CMake\bin

I suspect this is necessary for PyQt to find its plugins and the like, but the potential side effects are nasty, as you've found.

[jim-easterbrook]

Importing exiv2 also changes PATH (mea culpa, perhaps I need to do something about that) but the added directory only contains exiv2.dll and libcurl.dll.

(photini) C:\Users\Jim>python
Python 3.8.10 (tags/v3.8.10:3d8993a, May  3 2021, 11:48:03) [MSC v.1928 64 bit (
AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> print(os.environ['PATH'])
C:\Users\Jim\photini\Scripts;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Git\cmd;C:\Program Files\CMake\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Git\cmd;C:\Program Files\CMake\bin
>>> import exiv2
>>> print(os.environ['PATH'])
C:\Users\Jim\photini\lib\site-packages\exiv2\lib;C:\Users\Jim\photini\Scripts;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Git\cmd;C:\Program Files\CMake\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Git\cmd;C:\Program Files\CMake\bin

[jim-easterbrook]

This is an interesting read:
https://vinayak.io/2020/10/22/day-52-bundling-dlls-with-windows-wheels-the-dll-mangling-way/

It appears there isn't a simple solution for Windows builds, unlike Linux where there are tools to give shared library dependencies unique names and bundle them with the wheel. I think the DLLs bundled with python-exiv2 are fairly safe, as not many other packages would also depend on them. PyQt5 bundling MSVC runtimes is another matter though. I think you shouldn't bundle anything that would already be on a properly set up system, but maybe that doesn't apply to the MSVC runtime version that PyQt5 requires.

[jim-easterbrook]

I see that cibuildwheel (the tool I use to build binary wheels in a Github Action) has added delvewheel to sanitise shared libraries on Windows.
https://cibuildwheel.pypa.io/en/stable/changelog/#v400

Let the experimenting begin!