CODEWITHSUNDEEP
pythonwindowsdllpython-wheeltbb
Grant Karapetyan
Grant Karapetyan

Reputation: 66

vsruntime DLLs conflict after delvewheel repair

I am building wheel package for pypi, that usually is OK, but after updating some thirdparties I've got an error:

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

(I am using python 3.11.9)

Lets say I had good whl and now I have bad whl.

Both was repaired with delvewheel repair and both have same dlls including msvcp140-hash.dll, vcruntime140-hash.dll, vcruntime140_1-hash.dll (instead of hash there was some hash described here (Name Mangling section of delvewheel documentation))

So good whl works fine and bad one does not work. After hours of investigation I found out that using one of these options makes bad one work --no-dll "msvcp140.dll;vcruntime140_1.dll;vcruntime140.dll" or --no-mangle "msvcp140.dll;vcruntime140_1.dll;vcruntime140.dll".

It seems to me that there are some conflicts with original dlls in the system that produce that error:

  1. --no-dll excludes msvcp140-hash.dll, vcruntime140-hash.dll, vcruntime140_1-hash.dll from my package, so it just uses system dlls
  2. --no-mangle includes msvcp140.dll, vcruntime140.dll, vcruntime140_1.dll to my package without hash that makes system leave only one dll linked, that also prevents conflict

Interesting thing that good whl does not have this problem (it has same dependencies but some of them are older versions)

Have anyone faced something like this and what is the best way to fix it? (Would be nice if someone could explain why this issue happened, "dll conflicts" is just a theory based on symptoms)

UPDATE:

New founds: Looks like the reason is changes in onetbb library, especially this one

They added /DEPENDENTLOADFLAG:0x2000 to linker options that:

When the operating system resolves the statically linked imports of a module, it uses the default search order. Use the /DEPENDENTLOADFLAG option to specify a load_flags value that changes the search path used to resolve these imports. On supported operating systems, it changes the static import resolution search order, similar to what LoadLibraryEx does when using LOAD_LIBRARY_SEARCH parameters. For information on the search order set by load_flags, see Search order using LOAD_LIBRARY_SEARCH flags.

0x2000 means LOAD_LIBRARY_SAFE_CURRENT_DIRS

If this value is used, loading a DLL for execution from the current directory is only allowed if it is under a directory in the Safe load list.

So it turned out that during loading tbb12-hash.dll dll search paths was changed and msvcp140-hash.dll was not found.

Thanks!

Link to GitHub issue

Upvotes: 1

Views: 104

Answers (0)

Related Questions