zooba commented on issue #44855: URL: https://github.com/apache/arrow/issues/44855#issuecomment-2551589869
CPython doesn't ever include msvcp140.dll, or any other C++-only DLLs, and never has. If it's on the system, it's because something else installed it. And if something else has installed it, the only ways you're getting your own copy is to keep it alongside your extension module, put it alongside python.exe (please don't), or rename it and rewrite your module's import tables (like delvewheel does, IIUC). The download page at https://aka.ms/vcredist lists direct download links - e.g. https://aka.ms/vs/17/release/vc_redist.x64.exe for an Intel 64-bit OS. You can display these directly if you prefer, based on `platform.machine()`'s result. Using a renamed msvcp140.dll is likely to be okay provided that your module doesn't leak any C++ (objects or exceptions) into others. If everything is handled cleanly at Python boundaries, you should be equally fine with a renamed C++ runtime or static linking. As far as I'm aware, the msvcp140.dll is stateless, and all state is managed by vcruntime140.dll (which _is_ included with Python, and you should try and rely on the same instance). Overall, my recommendation for extension modules is to statically link the C++ runtime, and try to avoid sharing C++ objects with other libraries, except through your own APIs (they can handle a pointer and pass it back to you, but that's probably about it). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
