On Fri, 2 Nov 2012 15:20:10 -0400 Earnie Boyd <[email protected]> wrote:
> On Fri, Nov 2, 2012 at 3:01 PM, Jon wrote: > > > > I settled for the "fix" of using mingw.org gcc 4.6.2 32bit but don't > > understand why it works since the 4.6.2 .pyd's still have deps on > > msvcr90.dll and msvcrt.dll...need to try again with a custom spec to force > > everything to msvcr90.dll and try with > > http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.7.2/ > > > > There are ABI changes between mingw.org's 4.6.2 and 4.7 that require > all libraries to use one or the other. I don't know if nixMan's > releases would have the same issue but if it were me I would be sure > to rebuild all libraries and modules with the same compiler. You are > likely to have issues between mingw.org's gcc built libraries and > other's releases of gcc. Ah, good to know. My goal is to use the official Python binary (VC built?) and use mingw-w64 4.7.2 (Ruben or nixMan's) to build the modules, and not have to build everything with the same toolchain. I'm hoping my load fail (and the OP's) turns out to be the issue of modules linking against two different CRT versions. PeStudio tells me my msvcrt.dll linked .pyd's try to use _errno, __dllonexit, fflush, free, malloc, and strcmp from msvcr90.dll. Looks like the infamous crossing DLL boundries/separate DLL state issue that should disappear when linking against the same CRT. Jon ------------------------------------------------------------------------------ LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
