1

This question is a partial resolution to the question I posted today at CTypes error loading DLL that calls another DLL. I posted this as a separate post because the problem is in dependencies with the Python C/API, not in the source code that I posted there.

I have a 64-bit NASM dll that calls a 64-bit C dll on Windows 7. The C dll uses the Python C/API; the NASM dll is called using CTypes. However, when I load the NASM dll using ctypes in Visual Studio, I get the error "[WinError 126] The specified module could not be found." The C dll was compiled using GCC in MSYS2.

Calling the NASM dll into Dependency Walker showed that libpython3.6m.dll and libwinpthread-1.dll were missing. Those dlls are in the distribution for MSYS2, so I copied them from there into the folder containing the NASM dll. That fixed that problem, but now Dependency Walker says it's missing all these DLLs:

API-MS-WIN-CORE-COM-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
DCOMP.DLL
IESHIMS.DLL

This problem appears to be related to the Python C/API, which apparently depends on these DLLs. Does anyone know how to fix this? The full source code is at the link above.

RTC222
  • 2,025
  • 1
  • 20
  • 53
  • Are you using the official python.org Windows build of CPython 3.6, or a different one? – abarnert Apr 05 '18 at 00:58
  • Also, is the C DLL built against the same Python that you're running? – abarnert Apr 05 '18 at 00:59
  • For the C dll, I link to the Python 3.6 build that was installed with MSYS2; I have a separate Python 3.6.2 build that I use for regular work, but in this case I compiled and linked against the MSYS2 build. Is that the problem? – RTC222 Apr 05 '18 at 01:09
  • I was mainly wondering if you'd built it yourself, or used some unusual build, andif you'd built the C DLL against one Python but then tried to use it from a completely different Python. (Just having one on your machine shouldn't be an issue.) I'm a bit surprised that the standard MSYS2 version depends on WinRT, but I'm so out of date on that stuff that my surprise doesn't mean all that much… But maybe this info will help someone who knows more about modern-day MSYS builds than me. – abarnert Apr 05 '18 at 01:19
  • Yes, after the build I'm using it from my production Python 3.6.2 build. I don't yet know how to link against another Python from within MSYS2. – RTC222 Apr 05 '18 at 01:22
  • Hold on. So you're running a python.org Python 3.6, which is loading a DLL, which is linking another DLL which was built against an MSYS2 Python 3.6? I don't think that's supposed to work in general. – abarnert Apr 05 '18 at 01:24
  • I think you're zeroing in on it. I just have to work out the linker directives to link from MSYS2 directly to my regular Python 3.6.2 build, but I don't have the answer yet. I'd appreciate tips from anyone who knows how. – RTC222 Apr 05 '18 at 01:27
  • It's not the *Python* / *C* *API* that depends on those *.dll*s. The *.dll*s are part of the *VStudio* redistributable (everything built with *VStudio* needs them). *Google*ing any of those names would yield tons of useful articles. – CristiFati Apr 05 '18 at 09:08
  • But I have run NASM dlls from Visual Studio without any problems. Why does this one show dependencies that aren't there when other dlls run without problems? When I remove the C dll call from the NASM program, the NASM program runs. If Visual Studio was the problem, that wouldn't happen. – RTC222 Apr 05 '18 at 14:53
  • Again wrong assumption. It's the "C" *.dll* that needs those *.dll*s. Those *.dll*s are (obviously) installed on your machine (by *VStudio*), but *depends* simply doesn't know where to look for them. – CristiFati Apr 09 '18 at 09:52

0 Answers0