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

Reply via email to