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

Op 6 nov. 2012 06:40 schreef "Jim Michaels" het volgende: > > 32\errgw32bmatch2:bmatch2.cpp:404:49: error: no match for 'operator=' in 'iSpecAttrib = (& iSpecEl)->__gnu_cxx::__normal_iterator<_Iterator, _Container>::operator-> >()->SElement::lsAttributes.std::list<_Tp, _Alloc>::begin, std::allocat

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

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++) {        

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

32\errgw32bmatch2:bmatch2.cpp:404:49: error: no match for 'operator=' in 'iSpecAttrib = (& iSpecEl)->__gnu_cxx::__normal_iterator<_Iterator, _Container>::operator-> >()->SElement::lsAttributes.std::list<_Tp, _Alloc>::begin, std::allocator > >()' 32\errgw32bmatch2:bmatch2.cpp:404:93: error: n

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

Hi Yves, I searched cross-compiling issues at past. I've a project and have to compile on Windows(x86) and which will run on Linux(x86) I've only find a few blog entries(http://www.herbertm.ca/2006/01/compiling-x86-linux-under-win32/) http://www.herbertm.ca/2006/01/compiling-x86-under-darwin-osx/

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

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, which

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

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, which

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

On 11/5/12, Ruben Van Boxem wrote: > 2012/11/5 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

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

2012/11/5 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 comp

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

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

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/fi

[Mingw-w64-public] File too large?

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] RFC: How shall we plan releases of new major versions?

2012/11/5 JonY > On 11/5/2012 21:16, Ruben Van Boxem wrote: > > 2012/11/5 JonY > > > >> 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 th

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

On 11/5/2012 21:16, Ruben Van Boxem wrote: > 2012/11/5 JonY > >> 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 wo

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

2012/11/5 JonY > 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 without including any

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

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

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

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 without including any C++ headers first. Such as w

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

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

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

On 11/5/12, JonY 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 forgot to

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

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

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. Hi Alex, thanks for your suggestion, I would like to first try with