Hi, bad.pyd has a strange section .voltbl at the beginning. good.pyd looks as expected. (pyd-files are DLLs as used by CPython)
Carl Am Sa., 22. Jan. 2022 um 15:11 Uhr schrieb Matthew Brett < [email protected]>: > Hi, > > On Sat, Jan 22, 2022 at 12:40 PM Martin Storsjö <[email protected]> wrote: > > > > Hi, > > > > On Sat, 22 Jan 2022, Matthew Brett wrote: > > > > > The Scipy build links against a static library `npymath.lib`, until > > > recently built with VS2017 v141 toolset. > > > > Mixing static libraries or object files between mingw and msvc is not > > supported, and not expected to work, in general. You might have been > lucky > > and your library might have been simple enough not to hit any problematic > > case though. > > > > Or are the python pyd files linked with msvc tools - what parts are based > > on mingw in this constellation? > > We link the pyd files with mingw-w64. Specifically: > > Numpy build process: > > * Compiling npymath obj files from .c files - MSVC > * Assembling obj files into npymath.lib file - MSVC > > Scipy build process: > > * Linking npymath.lib file to pyd file - mingw-w64 > > I guess we were lucky, with the v141 build of npymath.lib, and less > so, for the v142 build. > > > > This build worked fine, until recently when the build for > > > `npymath.lib` switched to using the VS2019 v142 toolset. Our build > > > now runs to completion without error, but the generated dynamic link > > > libraries, _that link to the npymath.lib file_ all generate errors on > > > loading, of form: > > > > > > > C:\repos\scipy\installdir\Lib\site-packages\scipy\spatial\_distance_wrap.cp39-win_amd64.pyd > > > Error 193: > C:\repos\scipy\installdir\Lib\site-packages\scipy\spatial\_distance_wrap.cp39-win_amd64.pyd > > > is not a valid Win32 application. > > > > > > This is ERROR_BAD_EXE_FORMAT (193, 0xC1) > > > > So while this isn't a setup that is supported, this error doesn't sound > > like one of those that you'd expect to run into if mixing in msvc static > > libraries in a mingw environment. It sounds like some odd mixup of > > architectures or other details. > > > > I don't have any other clues offhand, but you'd have to sit down and > > inspect the generated dll (pyd) with tools like objdump, llvm-readobj > etc, > > to pinpoint what's wrong in it. > > Do you have any hints where we should be looking in the objdump etc > output? This repo has the pyd files with their respective: > > objdump -x > llvm-readobj --all > dlldiag trace > > outputs. > > https://github.com/matthew-brett/dll_investigation > > Error we see when importing the pyd file in Python replicated at: > > > https://github.com/matthew-brett/dll_investigation/blob/main/dlldiag_bad.txt#L47 > > in case there was anything very obvious to a quick glance. > > Cheers, > > Matthew > > > _______________________________________________ > Mingw-w64-public mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
