[Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)

[Václav Šmilauer]

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.


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 [!!]

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.


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

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)

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.


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.


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.
0x77c23522 in ntdll!ExpInterlockedPopEntrySListFault16 ()
   from C:\Windows\system32\ntdll.dll
(gdb) warning: HEAP[python.exe]:
warning: Invalid address specified to RtlSizeHeap( 003B, 
02306830 )


(gdb) bt
#0  0x77c23522 in ntdll!ExpInterlockedPopEntrySListFault16 ()
   from C:\Windows\system32\ntdll.dll
#1  0x77c0c241 in ntdll!RtlZeroHeap ()
   from C:\Windows\system32\ntdll.dll
#2  0x77c0c250 in ntdll!RtlZeroHeap ()
   from C:\Windows\system32\ntdll.dll
#3  0x77c3c130 in ntdll!LdrLoadAlternateResourceModuleEx ()
   from C:\Windows\system32\ntdll.dll
#4  0x003b in ?? ()
#5  0x02306830 in ?? ()
#6  0x003b in ?? ()
#7  0x792e21c0 in ?? ()
#8  0x003b in ?? ()
#9  0x77c3c0ba in ntdll!LdrLoadAlternateResourceModuleEx ()
   from C:\Windows\system32\ntdll.dll
#10 0x in ?? ()
#11 0x5061 in ?? ()
#12 0x in ?? ()|

Any hints on how to proceed would be appreciated.

Cheers,

Vaclav
--
Everyone hates slow websites. So do we.
Make y

Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)

[Алексей Павлов]

Hi, Vaclav!
Can you try to build python module with this
toolchain?
There are Python-2.7.3 in subdirectory "opt" compiled with this toolchain.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)

[JonY]

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.
> 0x77c23522 in ntdll!ExpInterlockedPopEntrySListFault16 ()
>from C:\Windows\system32\ntdll.dll
> (gdb) warning: HEAP[python.exe]:
> warning: Invalid address specified to RtlSizeHeap( 003B,
> 02306830 )
> 
> 
> (gdb) bt
> #0  0x77c23522 in ntdll!ExpInterlockedPopEntrySListFault16 ()
>from C:\Windows\system32\ntdll.dll
> #1  0x77c0c241 in ntdll!RtlZeroHeap ()
>from C:\Windows\system32\ntdll.dll
> #2  0x77c0c250 in ntdll!RtlZeroHeap ()
>fr

Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)

[John E. / TDM]

On 11/1/2012 4:11 PM, JonY wrote:
> On 11/1/2012 22:13, Václav Šmilauer wrote:
>> 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.

The _64 DLLs are, as one might guess, the 64-bit versions of GCC's 
runtime libraries. This is a TDM-GCC-specific change that allows them to 
coexist with the 32-bit versions.

Vaclav, the "-static-libstdc++" option is unrecognized by TDM-GCC 
because it uses static linkage by default. (This is covered in the 
TDM-GCC README.) Therefore, unless the projects you're building 
explicitly request shared runtimes (via "-shared-libgcc" and 
"-shared-libstdc++"), these DLLs will never be used, and renaming them 
serves no purpose. In fact, in the event that you *did* request shared 
runtime linkage, your program would be unable to run because it would be 
unable to find DLLs with the original _64-suffixed names.

I post this merely to clear up any confusion this TDM-GCC idiosyncrasy 
may cause -- unfortunately I don't have any insight as to the reason for 
the DLL load failure.

-John E. / TDM

--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)

[Jon]

> 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.


FYI, I had a similar (intermittent) runtime failure awhile ago on win7 ultimate 
32bit when trying to use the mercurial native module:

  http://sourceforge.net/mailarchive/message.php?msg_id=27964784

I thought it might be due to the official python27.dll being linked against 
mscvr90.dll while the .pyd's try to use both mscvr90.dll and msvcrt.dll. Never 
got time to go back and try to debug.

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/

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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)

[Earnie Boyd]

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.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)

[Jon]

On Fri, 2 Nov 2012 15:20:10 -0400
Earnie Boyd  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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)

[Václav Šmilauer]

Hi, Vaclav!
Can you try to build python module with this toolchain 
? 
There are Python-2.7.3 in subdirectory "opt" compiled with this toolchain.

Hi Alex,

thanks for your suggestion, I would like to first try with official 
python builds (msvc).


Did upstream python.org source for 2.7.3 compile cleanly with mingw or 
was some patching needed?


Cheers, Vaclav


--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)

[Václav Šmilauer]

>> 2a) [!!!] run gendef and dlltool on python27.dll
>> (http://stackoverflow.com/q/11182765/761090) to be able to -lpython27.
> How is that suspicious?
Having no experience here, I thought it was some hack. You seem to 
suggest this is the standard way. Good :-)
>> 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.
Does it mean there are different msvcr90.dll, which are not 
ABI-compatible? How do I find out which DLL do I need exactly then?
>> 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.
Later posts suggest this is TDM-specific, sorry for noise.
>> 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.
Not really a fix, just a workaround for my code:

#ifdef __MINGW64__
 #include
 template std::string to_string(const T& a){ return 
boost::lexical_cast(a); }
#endif

>> 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.
I reported both issues (it turns out they are related) to the tracker at 
https://sourceforge.net/tracker/?func=detail&aid=3584127&group_id=202880&atid=983354
 
.
>> 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.
>>
>> Any hints on how to proceed would be appreciated.
> Break at LoadLibrary and step from there?
I will try that - as last resort, though.

Cheers, Vaclav

--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)

[Václav Šmilauer]

>>> 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.
> The _64 DLLs are, as one might guess, the 64-bit versions of GCC's
> runtime libraries. This is a TDM-GCC-specific change that allows them to
> coexist with the 32-bit versions.
>
> Vaclav, the "-static-libstdc++" option is unrecognized by TDM-GCC
> because it uses static linkage by default. (This is covered in the
> TDM-GCC README.) Therefore, unless the projects you're building
> explicitly request shared runtimes (via "-shared-libgcc" and
> "-shared-libstdc++"), these DLLs will never be used, and renaming them
> serves no purpose. In fact, in the event that you *did* request shared
> runtime linkage, your program would be unable to run because it would be
> unable to find DLLs with the original _64-suffixed names.
>
> I post this merely to clear up any confusion this TDM-GCC idiosyncrasy
> may cause -- unfortunately I don't have any insight as to the reason for
> the DLL load failure.
Thanks for very valuable clarification. I am now thinking if I did not 
link (by asome accident) with a DLL compiled with the rubenvb build (I 
was experimenting with it briefly), therefore Dependency Walker showed 
me a DLL wanted to load libgcc_s_sjlj-1.dll, but it was a 32bit one 
instead of the 64bit one.

I think I will attempt a clean-install and clean-build before continuing 
any further.

Cheers, Vaclav

--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)

[Václav Šmilauer]

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.
We're on the same boat then. I cannot got 32bit as Jon did due to the 
4GB address-space restriction. The official python build is MSVC2008 
(http://stackoverflow.com/questions/2676763/what-version-of-visual-studio-is-this-python-compiled-with).


Please report any progress you have here or, if you think it is not 
appropriate, privately, I will be happy to hear about it.


If I can't get any further, I will play with Python built with MinGW 
(which is problematic in itself, though...).


Cheers, Vaclav

--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)

[Алексей Павлов]

Hi!
For building python with mingw you need some patches) You can find them  on
https://github.com/niXman/mingw-builds/tree/master/patches/Python-2.7.3.


2012/11/5 Václav Šmilauer 

>
>  Hi, Vaclav!
> Can you try to build python module with this 
> toolchain?
> There are Python-2.7.3 in subdirectory "opt" compiled with this toolchain.
>
> Hi Alex,
>
> thanks for your suggestion, I would like to first try with official python
> builds (msvc).
>
> Did upstream python.org source for 2.7.3 compile cleanly with mingw or
> was some patching needed?
>
> Cheers, Vaclav
>
>
>
>
> --
> 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
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)

[Václav Šmilauer]

> 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.
Just for the heck of it, I changed 
Python27/lib/distutils/cygwincompiler.py to return "msvcrt" instead of 
"msvcr90". It works.

My question is: do we really need to link our modules to msvcr*, if 
python.dll (which we link already when building modules) links to msvcrt 
itself? I assume there is a reason for that, but it is not clear to me. 
Maybe I am misunderstanding the difference in linking on Windows? Under 
Linux, linking is transitive, therefore if B (python) links to A 
(msvcrt), then C (my module) linking to B links to A automatically.

Cheers, Vaclav


--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)

[Václav Šmilauer]

>> 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.
> Just for the heck of it, I changed
> Python27/lib/distutils/cygwincompiler.py to return "msvcrt" instead of
> "msvcr90". It works.
I am confirming here that a rather complex compiled module loads (in 
terms of DLL getting loaded) when I link to msvcrt instead of msvcr90. I 
tried again to link to msvcr90, to make sure, and there was a failure. Yay!

Cheers!



--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)

[Earnie Boyd]

On Tue, Nov 6, 2012 at 5:04 AM, Václav Šmilauer  wrote:
>
>> 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.
> Just for the heck of it, I changed
> Python27/lib/distutils/cygwincompiler.py to return "msvcrt" instead of
> "msvcr90". It works.
>
> My question is: do we really need to link our modules to msvcr*, if
> python.dll (which we link already when building modules) links to msvcrt
> itself? I assume there is a reason for that, but it is not clear to me.
> Maybe I am misunderstanding the difference in linking on Windows? Under
> Linux, linking is transitive, therefore if B (python) links to A
> (msvcrt), then C (my module) linking to B links to A automatically.

See the following documents:
http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx
http://msdn.microsoft.com/en-us/library/ms235460.aspx

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)

[Václav Šmilauer]

>> Just for the heck of it, I changed
>> Python27/lib/distutils/cygwincompiler.py to return "msvcrt" instead of
>> "msvcr90". It works.
>>
>> My question is: do we really need to link our modules to msvcr*, if
>> python.dll (which we link already when building modules) links to msvcrt
>> itself? I assume there is a reason for that, but it is not clear to me.
>> Maybe I am misunderstanding the difference in linking on Windows? Under
>> Linux, linking is transitive, therefore if B (python) links to A
>> (msvcrt), then C (my module) linking to B links to A automatically.
> See the following documents:
> http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx
> http://msdn.microsoft.com/en-us/library/ms235460.aspx
Thanks for the references.

I double-checked python.exe/python27.dll, they link to 
c:\windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3c9a1e18e3b_9.0.30729.4940_none_08e4299fa83d7e3c\msvcr90.dll.
 
Since this directory is not in $PATH, it does not get picked up when the 
.pyd gets loaded (I had to copy msvcr90.dll to the directory, and there 
were two copies afterwards, which explains the crash).

I also tried to remove -lmsvcr* from the link command, and modules get 
compiled just fine. I know I am just trying random things, perhaps 
without proper understanding, but... why bother linking to msvcr* at 
all? Am I just lucky in this case?

Cheers, Vaclav



--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)

[Ruben Van Boxem]

2012/11/7 Václav Šmilauer 

>
> >> Just for the heck of it, I changed
> >> Python27/lib/distutils/cygwincompiler.py to return "msvcrt" instead of
> >> "msvcr90". It works.
> >>
> >> My question is: do we really need to link our modules to msvcr*, if
> >> python.dll (which we link already when building modules) links to msvcrt
> >> itself? I assume there is a reason for that, but it is not clear to me.
> >> Maybe I am misunderstanding the difference in linking on Windows? Under
> >> Linux, linking is transitive, therefore if B (python) links to A
> >> (msvcrt), then C (my module) linking to B links to A automatically.
> > See the following documents:
> > http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx
> > http://msdn.microsoft.com/en-us/library/ms235460.aspx
> Thanks for the references.
>
> I double-checked python.exe/python27.dll, they link to
>
> c:\windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3c9a1e18e3b_9.0.30729.4940_none_08e4299fa83d7e3c\msvcr90.dll.
> Since this directory is not in $PATH, it does not get picked up when the
> .pyd gets loaded (I had to copy msvcr90.dll to the directory, and there
> were two copies afterwards, which explains the crash).
>
> I also tried to remove -lmsvcr* from the link command, and modules get
> compiled just fine. I know I am just trying random things, perhaps
> without proper understanding, but... why bother linking to msvcr* at
> all? Am I just lucky in this case?
>

GCC for MinGW always links to msvcr.dll, which is an OS library. Linking to
another runtime afterwards will only resolve functions not present in
msvcrt.dll.

If it works, use what you have now. The only situation in which it's
problematic (I think) is when passing C objects across DLL boundaries as
you can read in the links. I'm not sure what this means for Python
explicitly...

Ruben


> Cheers, Vaclav
>
>
>
>
> --
> 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
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)

[Earnie Boyd]

On Wed, Nov 7, 2012 at 6:33 AM, Václav Šmilauer  wrote:
>
>>> Just for the heck of it, I changed
>>> Python27/lib/distutils/cygwincompiler.py to return "msvcrt" instead of
>>> "msvcr90". It works.
>>>
>>> My question is: do we really need to link our modules to msvcr*, if
>>> python.dll (which we link already when building modules) links to msvcrt
>>> itself? I assume there is a reason for that, but it is not clear to me.
>>> Maybe I am misunderstanding the difference in linking on Windows? Under
>>> Linux, linking is transitive, therefore if B (python) links to A
>>> (msvcrt), then C (my module) linking to B links to A automatically.
>> See the following documents:
>> http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx
>> http://msdn.microsoft.com/en-us/library/ms235460.aspx
> Thanks for the references.
>
> I double-checked python.exe/python27.dll, they link to
> c:\windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3c9a1e18e3b_9.0.30729.4940_none_08e4299fa83d7e3c\msvcr90.dll.
> Since this directory is not in $PATH, it does not get picked up when the
> .pyd gets loaded (I had to copy msvcr90.dll to the directory, and there
> were two copies afterwards, which explains the crash).

The only reason to not use msvcrt.dll is for newer functionality not
present in msvcrt.dll.  However, one should be careful to use one or
the other for memory and shared pointer functionality.  The
msvcr90.dll is distributed with a specific version of MSVC and is
allowed to be shared but only if the developer has licenses for that
right.  The msvcrt.dll is the common expected default library which is
what MinGW uses by default.

>
> I also tried to remove -lmsvcr* from the link command, and modules get
> compiled just fine. I know I am just trying random things, perhaps
> without proper understanding, but... why bother linking to msvcr* at
> all? Am I just lucky in this case?
>

I don't think any open source project should require a shared library
that isn't standard.  However, if there is a need then that open
source project should ensure that the crossing boundaries doesn't
happen.  Using LoadLibrary/GetProcAddress combo might help with that
so that you're using only the functions you require and not
encumbering the linker to decide.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public