On 11/1/2012 22:13, Václav Šmilauer wrote: > Hi everybody, > > I am fairly new to MinGW64 (and to windows) and this is my first post to > the list. I would like to thank to the authors of and contributors to > mingw64 in the first place. > > I am trying to build compiled python modules, which use some compiled > libraries (boost, in particular). The system is Windows 7 64bit Pro. One > of them (http://pypi.python.org/pypi/minieigen/0.3-4) works fine, > another one (source not publicly available yet) does not. > > I hit quite a few problems underways and will be reporting them to > upstreams in the days to come.I would like to outline the procedure > (therefore is the message a bit lengthy) I was following so that those > who are experienced could point out which steps were perhaps leading to > later troubles - I marked suspicious points with [!!!]. > > 1. I installed tdm-gcc 4.7.1 targeting x86_64 (I was also trying > personal build of 4.7.2 from rubenvb, with same result) and MSYS. Both > were added to the path. > > 2. I installed python 2.7.3 using the pre-built (MSVC) x86-64 installer > provided by python.org; I had to: > > 2a) [!!!] run gendef and dlltool on python27.dll > (http://stackoverflow.com/q/11182765/761090) to be able to -lpython27. >
How is that suspicious? > 2b) fix Python27/Lib/distutils/cygwincompiler.py to get rid of > -mno-cygwin (http://bugs.python.org/issue12641) > > 2c) Add python to $PATH > > 2d) Create ~/pydistutils.cfg containing "[build]\ncompiler=mingw32" so > that it is used automatically by distutils > > 3. Fix DLLs [!!!!!!] > Fix what? > 3a) Copy msvcr90.dll (c:\Windows\winsxs > \amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.21022.8_none_750b37ff97f4f68b\mscvr90.dll) > somewhere to $PATH (c:\Python27) so that it is in $PATH for dynamic > loader. Python is compiled against msvcr90.dll by upstream. > No you don't, copying the DLL does not mean you grabbed the correct mscvr90.dll version. > 3b) Likewise for ieshims.dll (c:\Program Files\Internet > Explorer\ieshims.dll) > > 3c) Move 32bit libs out of the way > (http://gcc.gnu.org/ml/gcc-help/2012-07/msg00060.html suggests to use > -static-libstdc++, but it is not recognized by gcc 4.7); I don't compile > 32bit programs, so not having 32bit versions is fine for me: > > cd /c/MinGW64/bin > mv libstdc++-6.dll libstdc++-6.dll.~32bit~ > cp libstdc++_64-6.dll libstdc++-6.dll > mv libgcc_s_sjlj-1.dll libgcc_s_sjlj-1.dll.~32bit~ > cp libgcc_s_shlj_64-1.dll libgcc_s_sjlj-1.dll > I have no idea why your DLLs are named that way, are you sure you are supposed to rename them? Ask TDM for more info. > 3. I downloaded and compiled boost 1.51.0, bootstrapped for gcc, applied > some workarounds (http://stackoverflow.com/a/1737887/761090), downloaded > sources for zlib and bzip2, compiled with variant=release link=shared > threading=multi. Examples for boost::python was running fine. > > 4. Unpack http://eigen.tuxfamily.org/ (header-only lib), needed for next > step > > 4. Fix some headers in gcc (this was needed for the next step) > > 4a) Fix to_string with c++11 (gcc.gnu.org/bugzilla/show_bug.cgi?id=52015) > What exactly did you do? The patch posted requires cooperation from the C headers, that part is only in svn trunk. > 4b) In c:\MinGW64\x86_64_w64-mingw32\include\stdlib.h, comment out > functions wtoll, lltow, ulltow at lines 626-628. This was only triggered > when including Eigen with vectorization - will be reported separately soon. > What, it defines it's own copies? > 4c) In c:\MinGW64\x86_64_w64-mingw32\include\sys\stat.h, replace #ifndef > __CRT_NO_INLINE by #if 0 (errors about undefined struct in _fstat632) - > will be reported separately soon. > I have no idea how you got that error when the struct was declared just above from an include. > 5) easy_install minieigen - this actually compiled the module flawlessly > now, and it works. > > Now the problem: > > Another rather large module fails to load with "DLL load failed: Invalid > access to memory location". I am wrestling to find out what it wrong. > Asking at > http://stackoverflow.com/questions/13173944/how-to-debug-dll-load-failed-invalid-access-to-memory-location > did not help (I am re-posting a part of that here now). DrMinGW64 does > not show any useful stack trace. The dynamic loader at windows only > reports error and does not show any further information: > > |Program received signal SIGTRAP, Trace/breakpoint trap. > 0x0000000077c23522 in ntdll!ExpInterlockedPopEntrySListFault16 () > from C:\Windows\system32\ntdll.dll > (gdb) warning: HEAP[python.exe]: > warning: Invalid address specified to RtlSizeHeap( 00000000003B0000, > 0000000002306830 ) > > > (gdb) bt > #0 0x0000000077c23522 in ntdll!ExpInterlockedPopEntrySListFault16 () > from C:\Windows\system32\ntdll.dll > #1 0x0000000077c0c241 in ntdll!RtlZeroHeap () > from C:\Windows\system32\ntdll.dll > #2 0x0000000077c0c250 in ntdll!RtlZeroHeap () > from C:\Windows\system32\ntdll.dll > #3 0x0000000077c3c130 in ntdll!LdrLoadAlternateResourceModuleEx () > from C:\Windows\system32\ntdll.dll > #4 0x00000000003b0000 in ?? () > #5 0x0000000002306830 in ?? () > #6 0x00000000003b0000 in ?? () > #7 0x00000000792e21c0 in ?? () > #8 0x00000000003b0000 in ?? () > #9 0x0000000077c3c0ba in ntdll!LdrLoadAlternateResourceModuleEx () > from C:\Windows\system32\ntdll.dll > #10 0xffffffffffffffff in ?? () > #11 0x0000000050000061 in ?? () > #12 0x0000000000000000 in ?? ()| > > Any hints on how to proceed would be appreciated. Break at LoadLibrary and step from there?
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
