Конфликт библиотек vsruntime после ремонта delvewheel ⇐ Python

[Anonymous]

Я создаю пакет Wheel для pypi, обычно это нормально, но после обновления некоторых сторонних разработчиков у меня возникла ошибка:

Код: Выделить всё

>>> from meshlib import mrmeshpy as mm
Traceback (most recent call last):
File "", line 1, in 
ImportError: DLL load failed while importing mrmeshpy: The specified module could not be found.

(Я использую Python 3.11.9)

Допустим, у меня было хорошо whl, и теперь у меня плохой whl.
Оба были восстановлены с помощью delvewheel Repair, и обе имеют одинаковые библиотеки DLL, включая msvcp140-hash.dll, vcruntime140-hash.dll, vcruntime140_1-hash.dll (вместо хэша был описан какой-то хеш (раздел «Имя искажения» документации delvewheel))
Итак, хороший работает нормально, а плохой не работает. После нескольких часов исследования я обнаружил, что использование одного из этих параметров делает работу плохой --no-dll "msvcp140.dll;vcruntime140_1.dll;vcruntime140.dll" или --no -mangle "msvcp140.dll;vcruntime140_1.dll;vcruntime140.dll".
Мне кажется, что в системе есть некоторые конфликты с исходными dll, которые вызывают эту ошибку :

• Код: Выделить всё

  --no-dll

  исключает msvcp140-hash.dll, vcruntime140-hash.dll, vcruntime140_1-hash.dll из моего пакета, поэтому он использует только системные библиотеки DLL

• Код: Выделить всё

  --no-mangle

  включает msvcp140.dll, vcruntime140.dll, vcruntime140_1.dll в мой пакет без хеша, что заставляет систему оставлять только одну связанную dll, которая также предотвращает конфликты

Интересно, что good whl не имеет этой проблемы (у него те же зависимости, но некоторые из них старше версии)

Сталкивался ли кто-нибудь с подобным и как лучше всего это исправить? (Было бы неплохо, если бы кто-нибудь объяснил, почему возникла эта проблема, «конфликты dll» — это всего лишь теория, основанная на симптомах)

ОБНОВЛЕНИЕ:
Новые находки:
Похоже, причина в изменениях в библиотеке onetbb, особенно в этой.
Они добавили /DEPENDENTLOADFLAG:0x2000 в компоновщик. параметры, которые:

Когда операционная система разрешает статически связанный импорт модуля, она использует порядок поиска по умолчанию. Используйте параметр /DEPENDENTLOADFLAG, чтобы указать значение load_flags, которое изменяет путь поиска, используемый для разрешения этого импорта. В поддерживаемых операционных системах он меняет порядок поиска статического разрешения импорта, аналогично тому, что делает LoadLibraryEx при использовании параметров LOAD_LIBRARY_SEARCH. Информацию о порядке поиска, установленном load_flags, см. в разделе Порядок поиска с использованием флагов LOAD_LIBRARY_SEARCH.

0x2000 означает LOAD_LIBRARY_SAFE_CURRENT_DIRS

Если используется это значение, загрузка DLL для выполнения из текущего каталога разрешена только в том случае, если она находится в каталоге в списке безопасной загрузки.
< /blockquote>
Так получилось, что во время загрузки tbb12-hash.dll были изменены пути поиска dll и msvcp140-hash.dll не найден.
Спасибо!
Ссылка на проблему GitHub

Подробнее здесь: https://stackoverflow.com/questions/788 ... eel-repair