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

2012-11-05 Thread Václav Šmilauer
Hi, Vaclav! Can you try to build python module with this toolchain https://www.dropbox.com/s/hwst18lywbw74vv/x64-4.7.2-release-posix-sjlj-rev1.7z? 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

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major versions?

2012-11-05 Thread JonY
On 10/29/2012 01:30, Kai Tietz wrote: JonY, please sent patch upstream to gcc's and libstdc++'s ML. Add me CC and please mention that I ok'ed patch on IRC. I won't be able to reply next week myself. Cheers, Kai OK, it's in, but I forgot to announce it. To use std::to_string and

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major versions?

2012-11-05 Thread Ozkan Sezer
On 11/5/12, JonY jo...@users.sourceforge.net wrote: On 10/29/2012 01:30, Kai Tietz wrote: JonY, please sent patch upstream to gcc's and libstdc++'s ML. Add me CC and please mention that I ok'ed patch on IRC. I won't be able to reply next week myself. Cheers, Kai OK, it's in, but I

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

2012-11-05 Thread 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

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

2012-11-05 Thread 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

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major versions?

2012-11-05 Thread Ruben Van Boxem
2012/11/5 JonY jo...@users.sourceforge.net On 11/5/2012 20:44, Ozkan Sezer wrote: If older gcc (I guess 4.6 is common as the old gcc) is OK with it, then please go ahead. When you put it that way, it suddenly hit me that the vfwsprintf will not really work if the user set -std=c++11

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major versions?

2012-11-05 Thread JonY
On 11/5/2012 21:16, Ruben Van Boxem wrote: 2012/11/5 JonY jo...@users.sourceforge.net On 11/5/2012 20:44, Ozkan Sezer wrote: If older gcc (I guess 4.6 is common as the old gcc) is OK with it, then please go ahead. When you put it that way, it suddenly hit me that the vfwsprintf will not

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major versions?

2012-11-05 Thread Ruben Van Boxem
2012/11/5 JonY jo...@users.sourceforge.net On 11/5/2012 21:16, Ruben Van Boxem wrote: 2012/11/5 JonY jo...@users.sourceforge.net On 11/5/2012 20:44, Ozkan Sezer wrote: If older gcc (I guess 4.6 is common as the old gcc) is OK with it, then please go ahead. When you put it that

[Mingw-w64-public] File too large?

2012-11-05 Thread Václav Šmilauer
Hi everybody, I was hitting the File too large error triggered by as.exe trying to write some files. I somehow managed to work around it by splitting compilation in smaller parts, by compiling without -g and/or with -Os. Why is it that a native 64bit compiler is hitting this 32bit limit? Is

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

2012-11-05 Thread 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

Re: [Mingw-w64-public] File too large?

2012-11-05 Thread Ruben Van Boxem
2012/11/5 Václav Šmilauer e...@doxos.eu Hi everybody, I was hitting the File too large error triggered by as.exe trying to write some files. I somehow managed to work around it by splitting compilation in smaller parts, by compiling without -g and/or with -Os. Why is it that a native 64bit

Re: [Mingw-w64-public] MinWG64 on Windows, for Windows?

2012-11-05 Thread Yves
Hi Ruben, All the while I tried all packages, since I`m still oscillating between 32 bit and 64 bit, TDM seemed to be the way to go, at least to compile to compile on Windows for Windows. As far as I can tell, none of the packages you suggested allow cross compiling. With this in mind,

Re: [Mingw-w64-public] MinWG64 on Windows, for Windows?

2012-11-05 Thread Yves
Hi Ruben, All the while I tried all packages, since I`m still oscillating between 32 bit and 64 bit, TDM seemed to be the way to go, at least to compile to compile on Windows for Windows. As far as I can tell, none of the packages you suggested allow cross compiling. With this in mind,

[Mingw-w64-public] bug in gcc? has nothing defined for iterator references

2012-11-05 Thread Jim Michaels
32\errgw32bmatch2:bmatch2.cpp:404:49: error: no match for 'operator=' in 'iSpecAttrib = ( iSpecEl)-__gnu_cxx::__normal_iterator_Iterator, _Container::operator-SElement*, std::vectorSElement ()-SElement::lsAttributes.std::list_Tp, _Alloc::beginstd::basic_stringchar,

Re: [Mingw-w64-public] clarification - iterator references

2012-11-05 Thread Jim Michaels
the alternative code I came up with is bool attribNameIsInSpecElement(std::string tagName, std::string sattrib, VSEI* piSpecEl, LSAI* piSpecAttrib, bool isXHTML, bool isXML) {     for (piSpecEl = (vseSpecElements.begin());         *piSpecEl != vseSpecElements.end();         *piSpecEl++) {        

Re: [Mingw-w64-public] bug in gcc? has nothing defined for iterator references

2012-11-05 Thread Ruben Van Boxem
Op 6 nov. 2012 06:40 schreef Jim Michaels jmich...@yahoo.com het volgende: 32\errgw32bmatch2:bmatch2.cpp:404:49: error: no match for 'operator=' in 'iSpecAttrib = ( iSpecEl)-__gnu_cxx::__normal_iterator_Iterator, _Container::operator-SElement*, std::vectorSElement