0

I'm trying to build a python c extension on windows with msvc (using distutils) which links in some other static libraries.

Basically I have test1.lib, test2.lib and test3.obj and want to build test4.dll which has test1.lib, test2.lib and test3.obj linked in.

I've inspected the generated dll with depends.exe and it is expecting a test1.dll and test2.dll.

Any ideas on how to tell msvc to properly link the files?

Here is the actual build command:

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\x86_amd64\link.exe /nologo /INCREMENTAL:NO /LTCG /DLL /MANIFEST:EMBED,ID=2 /MANIFESTUAC:NO /LIBPATH:C:\app\backend\opc_ua\ua_sd
k\lib /LIBPATH:C:\app\backend\opc_ua\ua_sdk\third-party\win64\vs2015\libxml2\out32dll /LIBPATH:C:\app\backend\opc_ua\ua_sdk\third-party\win64\vs2015\openssl\out32dll /LIBPATH:C:\Pyth
on-3.7.2-amd64\libs /LIBPATH:C:\Python-3.7.2-amd64\PCbuild\amd64 "/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\amd64" "/LIBPATH:C:\Program Files (x86)\Windows Kits\10\
lib\10.0.10240.0\ucrt\x64" "/LIBPATH:C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x64" ws2_32.lib advapi32.lib uamodule.lib coremodule.lib uapkicpp.lib uabasecpp.lib xmlparsercpp.l
ib uastack.lib libxml2.lib libssl.lib libcrypto.lib mpr.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib /EXPORT:PyInit_opcua
build\temp.win-amd64-3.7\Release\uniauto_cpp\opcuamodule.obj build\temp.win-amd64-3.7\Release\uniauto_cpp\NodeManager.obj build\temp.win-amd64-3.7\Release\uniauto_cpp\opcserver.obj
 build\temp.win-amd64-3.7\Release\uniauto_cpp\uamodeler_output\instancefactory_.obj build\temp.win-amd64-3.7\Release\uniauto_cpp\uamodeler_output\nodemanager.obj build\
temp.win-amd64-3.7\Release\uniauto_cpp\uamodeler_output\nodemanagerbase.obj /OUT:build\lib.win-amd64-3.7\opcua.cp37-win_amd64.pyd /IMPLIB:build\temp.win-amd64-3.7\Release\uni
auto_cpp\opcua.cp37-win_amd64.lib

And depends.exe says the output file depends on uastack.dll, libxml2.dll, libcrypto.dll when they are clearly listed in their .lib format.

mitch
  • 37
  • 6
  • Q: Are you getting any errors when you link your .exe or.dll in MSVS? If so, please update your post with the error. Otherwise, please clarify exactly the problem is. Q: Are you sure Python and *all* .dlls are consistently either 32 or 64 bit? Q: Do you happen to have copies of the other .dlls "depends" says you need? – paulsm4 Sep 26 '19 at 06:09
  • There are no linker errors. The exact problem is that when I try to import the library into python I get a "ImportError: DLL load failed:" error. When I examine the pyd file in depends.exe the dll is looking for uastack.dll, libxml2.dll, libcrypto.dll despite the fact they are static libraries and should have been linked in when building the dll – mitch Sep 26 '19 at 06:27
  • 1
    Ah - now I understand. You thought just because you had a .lib, the MSVS linker would statically add its contents to your .dll. No - it doesn't necessarily work like that :) Q: Do you happen to have copies of the other .dlls "depends" says you need? Q: Does your Python extension "work" if you copy the dependent .dlls into your %PATH% (or into Windows\System32)? – paulsm4 Sep 26 '19 at 23:25
  • 2
    Those .lib files are [import libraries](https://learn.microsoft.com/en-us/windows/win32/dlls/about-dynamic-link-libraries). They don't contain actual code (you may notice that they are tiny, much smaller than their corresponding DLLs). They merely help the linker to set up dependencies on symbols exported from the DLL. The DLL is needed at runtime - that's where the code lives. – Igor Tandetnik Sep 27 '19 at 23:20
  • I'm voting to close this question as off-topic because: misunderstanding. – paulsm4 Sep 27 '19 at 23:54
  • Hmm, okay. I'll look into it a bit more Monday but there are no DLLs with those names, only .libs. Creating an exe from a sample visual studio project works with no issues so I assume whatever is needed is somewhere on the path, strange python isn't finding it. Thanks, you've given me some ideas! Will let you know how I go – mitch Sep 28 '19 at 01:12
  • You are indeed correct the .lib points to another dll. Rookie error. Thanks for your help – mitch Sep 30 '19 at 00:18

0 Answers0