I opened an github issue on that topic: https://github.com/matthew-brett/dll_investigation/issues/1
Carl Am Sa., 22. Jan. 2022 um 15:56 Uhr schrieb Carl Kleffner < cmkleff...@gmail.com>: > 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 < > matthew.br...@gmail.com>: > >> Hi, >> >> On Sat, Jan 22, 2022 at 12:40 PM Martin Storsjö <mar...@martin.st> 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 >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> > _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
