Re: [Mingw-w64-public] RFC: How shall we plan releases of new major versions?
On 11/5/2012 21:31, Ruben Van Boxem wrote: 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 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 when the use include stdio.h directly. Any suggestions? The guard macro is: #if defined(__cplusplus) (__cplusplus = 201103L) !defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF) _GLIBCXX_HAVE_BROKEN_VSWPRINTF will be set (or not) only after including some basic C++ headers. Basically, I didn't want users to be caught surprised. Any changes would be on the mingw-w64 side, since the gcc change was just removing _GLIBCXX_HAVE_BROKEN_VSWPRINTF to allow to_string to be used. The way it would work now, the declaration of a C function would depend on the C++ standard in effect. This is mildly worrying and very unexpected. How much trouble would it be to only have the std::vswprintf work in a C99 way, and leave ::vswprintf as the broken C function. This would require accommodation by libstdc++ (not sure how receptive they are for these kinds of changes), and would at least provide a consistent declaration of the C function. They aren't really accepting of OS specific hacks. IMHO, that's just stupid. A C++ library is a layer atop an OS. There's bound to be incompatibilities. If they're not willing to have OS specific things in their code, why check for every damn function you use and work around missing ones? /rant Actually, according to http://msdn.microsoft.com/en-us/library/28d5ce15%28v=vs.80%29.aspx In Visual C++ 2005, vswprintf conforms to the ISO C Standard, which requires the second parameter, count, of type size_t. To force the old nonstandard behavior, define _CRT_NON_CONFORMING_SWPRINTFS. The old behavior may not be in a future version, so code should be changed to use the new conformant behavior. We do that to mingw-w64 too? MSVC has this behavior since 2005. Obviously it will break if user defines _CRT_NON_CONFORMING_SWPRINTFS and C++11 at the same time, but that would be PEBCAK. 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] bug in gcc? dereferencing pointers to iterators
somehow I think pointers are the way to go when modifying an iterator function
argument. but I am having problems. I have a pointer to an iterator.
gcc wants me to dereference a *third* time. it says to use - and I know a-b
is the same as *a.b
but gcc doesn't see it this way I guess. or again I am not understanding
something.
I already trieddoing *iSpecEl-tagName and this does not work. it gives me an
error.
EVERYTHING I have tried gives me an error.
how can this be? I know you dereference iterators using * and same with
pointers. so I had to (I thought) do a double dereference here. here is latest
code:
typedef struct SBraceNode {
int64_t lineNumber, columnNumber;
uint32_t ch;
} SBraceNode;
typedef struct {
std::string
name,
val;
bool isBoolean;
VUI hitLineNumbers;
} SAttribute;
typedef std::listSAttribute LSA;
typedef std::listSAttribute::iterator LSAI;
typedef std::liststd::string LS;
typedef std::liststd::string::iterator LSI;
LSA lsGlobalIDs;
typedef std::vectorstd::string VS;
VS vsDoctypes;
typedef struct SElement {
std::string tagName;
bool isVoid; //void element/singleton
bool isScriptOrStyle; //for these, we ignore any opening and closing braces
and look for /script tags
bool hasSlash;
SBraceNode
sbnOpenStart, //start of open tag
sbnOpenEnd, //end of open tag
sbnCloseStart,//start of close tag
sbnCloseEnd; //end of close tag
LS lsAttributes;
} SElement;
typedef std::vectorSElement VSE;
typedef std::vectorSElement::iterator VSEI;
bool attribNameIsInSpecElement(std::string tagName, std::string sattrib, VSEI*
piSpecEl, LSAI* piSpecAttrib, bool isXHTML, bool isXML) {
//*piSpecEl is the iterator for the spec element
//**piSpecEl is the element
//*piSpecAttrib is the iterator for the spec attribute
//**piSpecAttrib is the attribute
for (piSpecEl = (vseSpecElements.begin());
*piSpecEl != vseSpecElements.end();
*piSpecEl++) {
if (compare(tagName,**piSpecEl.tagName,isXHTML,isXML)) {
for (piSpecAttrib = (**piSpecEl.lsAttributes.begin());
*piSpecAttrib != **piSpecEl.lsAttributes.end();
*piSpecAttrib++) {
if (compare(**piSpecAttrib.name,sattrib,isXHTML,isXML)) {
//at this point, iAttrib and iSpecEl both point to valid
attribute and element.
return true;
}
}
}
}
//at this point, iSpecEl points to vseSpecElement.end() and iAttrib points
to lsAttributes.end()
return false;
}
I could not use *piSpecEl-tagName because this caused an error.
I can't use **piSpecEl.tagName because this causes an *error* in gcc and it
says perhaps you wanted to use - ?
64\errgw64bmatch2:bmatch2.cpp:405:34: error: request for member 'tagName' in
'piSpecEl', which is of pointer type 'VSEI* {aka __gnu_cxx::__normal_iter
atorSElement*, std::vectorSElement *}' (maybe you meant to use '-' ?)
64\errgw64bmatch2:bmatch2.cpp:406:37: error: request for member 'lsAttributes'
in 'piSpecEl', which is of pointer type 'VSEI* {aka __gnu_cxx::__normal
_iteratorSElement*, std::vectorSElement *}' (maybe you meant to use '-' ?)
64\errgw64bmatch2:bmatch2.cpp:407:36: error: request for member 'lsAttributes'
in 'piSpecEl', which is of pointer type 'VSEI* {aka __gnu_cxx::__normal
_iteratorSElement*, std::vectorSElement *}' (maybe you meant to use '-' ?)
64\errgw64bmatch2:bmatch2.cpp:409:32: error: request for member 'name' in
'piSpecAttrib', which is of pointer type 'LSAI* {aka std::_List_iteratorSAt
tribute*}' (maybe you meant to use '-' ?)
From: Ruben Van Boxem vanboxem.ru...@gmail.com
To: mingw-w64-public@lists.sourceforge.net
Sent: Monday, November 5, 2012 11:52 PM
Subject: Re: [Mingw-w64-public] bug in gcc? has nothing defined for iterator
references
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
()-SElement::lsAttributes.std::list_Tp,
_Alloc::beginstd::basic_stringchar,
std::allocatorstd::basic_stringchar ()'
32\errgw32bmatch2:bmatch2.cpp:404:93: error: no match for 'operator!=' in
'iSpecAttrib != ( iSpecEl)-__gnu_cxx::__normal_iterator_Iterator,
_Container::operator-SElement*, std::vectorSElement
()-SElement::lsAttributes.std::list_Tp,
_Alloc::endstd::basic_stringchar, std::allocatorstd::basic_stringchar
()'
typedef struct {
std::string
name,
val;
bool isBoolean;
VUI hitLineNumbers;
} SAttribute;
typedef std::listSAttribute LSA;
typedef std::listSAttribute::iterator LSAI;
bool attribNameIsInSpecElement(std::string tagName, std::string attrib,
VSEI iSpecEl, LSAI iSpecAttrib, bool isXHTML, bool isXML) {
Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)
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] MinWG64 on Windows, for Windows?
that would be nice... From: Yves yves.per...@modusfx.com To: mingw-w64-public@lists.sourceforge.net mingw-w64-public@lists.sourceforge.net Sent: Monday, November 5, 2012 10:49 AM Subject: 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 package should I use to compile on Windows for Linux? You probably see it coming… which package should I use to compile on Windows for MacOSX? In another words, what solution is there to cross compile on Windows, for Windows, Linux and MacOSX? Sent from my iPhone On Nov 2, 2012, at 18:11, Yves yves.per...@modusfx.com wrote: Very well, I'll chew on this over the weekend. Your wisdom is appreciated indeed. Thank you very much Ruben. Sent from my iPhone On Nov 2, 2012, at 15:55, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: 2012/11/2 Yves Perron yves.per...@modusfx.com Greetings everyone, Its been a wild ride for me in the cross-platform compilation world. After several weeks pulling my hair, I figured it might be a good thing to ask for help before I go completely bald. To resume, I do have a fairly complex C++ Visual Studio 10 Win64 project that needs to be maintained on windows and port to Linux and MacOSX. For simplicity sake, let's forget I just said that and let's get down to basics. Here is my setup: Windows 7 CMake 2.8.9 Intel Processor 64 bit I already have my CMake setup running using the Visual Studio 10 Win64 compiler and it works beautifully. Now, to get things rolling, I'd like to compile the same project with MinWG64 on Windows, for Windows. Hi Yves, Before I go any further, I'd like to know: * Which MinGW64 binary package should I get from http://sourceforge.net/projects/mingw-w64?** There are several you can choose from: - my Personal builds: I provide native and cross compilers which are nicely up to date. Choose the 4.7.2 package if you want to have the latest stable stuff. - mingwbuilds: another person who reads this list and builds compilers. He often has very specialized features enabled which I reserve for my experimental builds. - TDM GCC: a MinGW classic, providing a 32-bit Windows to 64-bit Windows multilib compiler (which can compile for both 32 and 64-bit) All of these are either install+ add mingw*/bin to PATH or run the included envsetup script which does that for you (like with mine). It goes without saying I recommend my toolchain builds ;-) * What would be the best compiler to use to get my code compliant for the other platforms? You should use as much compilers as possible, which in this case means: Visual Studio (which will be the limiting factor in any case), GCC (see above) and Clang (see http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/clang-3.1-release/ for more details, read carefully). Clang may not be usable for what you are doing, as it misses certain features required for normal Windows code (like dllexporting classes). It works fine in cases not using that though, but only for 32-bit Windows. To force GCC's strict mode, which is very useful, use the following compiler flags when building: -Wextra -pedantic -std=c++11 Some optional extra flags are: -Wconversion -Wuninitialized -Winit-self -Wmissing-include-dirs -Wstrict-aliasing These options will not ensure your code will work on different OSes, but it will make sure it is standards conformant as much as possible. Note that MinGW inherently uses msvcrt, which means certain C functions may not behave like you would expect. See MSDN in Visual C++ 2003 mode to see the documentation for the functions MinGW exposes. If you're using fancy C++11 library features (which include but are not limited to thread, std::to_string, and regex) you will find GCC's libstdc++ unfortunately lacking. Everything else is usually implemented better than on MSVC though, including tuple. To use CMake, just be sure g++ is in PATH, and run cmake path/to/source -GMinGW Makefiles Hope this helps, Ruben ** I say binary hoping I could avoid compiling compilers because this idea upsets me some how. Thank you very much for reading this. -- 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
Re: [Mingw-w64-public] bug in gcc? dereferencing pointers to iterators
Op 6 nov. 2012 11:04 schreef Jim Michaels jmich...@yahoo.com het
volgende:
somehow I think pointers are the way to go when modifying an iterator
function argument. but I am having problems. I have a pointer to an
iterator.
An iterator is the generalization of pointers for non-sequential
containers. Pass them by value.
gcc wants me to dereference a *third* time. it says to use - and I know
a-b is the same as *a.b
but gcc doesn't see it this way I guess. or again I am not understanding
something.
I already tried doing *iSpecEl-tagName and this does not work. it gives
me an error.
EVERYTHING I have tried gives me an error.
how can this be? I know you dereference iterators using * and same with
pointers. so I had to (I thought) do a double dereference here. here is
latest code:
typedef struct SBraceNode {
int64_t lineNumber, columnNumber;
uint32_t ch;
} SBraceNode;
typedef struct {
std::string
name,
val;
bool isBoolean;
VUI hitLineNumbers;
} SAttribute;
typedef std::listSAttribute LSA;
typedef std::listSAttribute::iterator LSAI;
typedef std::liststd::string LS;
typedef std::liststd::string::iterator LSI;
LSA lsGlobalIDs;
typedef std::vectorstd::string VS;
VS vsDoctypes;
typedef struct SElement {
std::string tagName;
bool isVoid; //void element/singleton
bool isScriptOrStyle; //for these, we ignore any opening and closing
braces and look for /script tags
bool hasSlash;
SBraceNode
sbnOpenStart, //start of open tag
sbnOpenEnd, //end of open tag
sbnCloseStart,//start of close tag
sbnCloseEnd; //end of close tag
LS lsAttributes;
} SElement;
typedef std::vectorSElement VSE;
typedef std::vectorSElement::iterator VSEI;
bool attribNameIsInSpecElement(std::string tagName, std::string sattrib,
VSEI* piSpecEl, LSAI* piSpecAttrib, bool isXHTML, bool isXML) {
//*piSpecEl is the iterator for the spec element
//**piSpecEl is the element
//*piSpecAttrib is the iterator for the spec attribute
//**piSpecAttrib is the attribute
for (piSpecEl = (vseSpecElements.begin());
*piSpecEl != vseSpecElements.end();
*piSpecEl++) {
if (compare(tagName,**piSpecEl.tagName,isXHTML,isXML)) {
for (piSpecAttrib = (**piSpecEl.lsAttributes.begin());
*piSpecAttrib != **piSpecEl.lsAttributes.end();
*piSpecAttrib++) {
if (compare(**piSpecAttrib.name,sattrib,isXHTML,isXML)) {
//at this point, iAttrib and iSpecEl both point to
valid attribute and element.
return true;
}
}
}
}
//at this point, iSpecEl points to vseSpecElement.end() and iAttrib
points to lsAttributes.end()
return false;
}
I could not use *piSpecEl-tagName because this caused an error.
I can't use **piSpecEl.tagName because this causes an *error* in gcc and
it says perhaps you wanted to use - ?
This is due to operator precedence. Use parenthesis if you really want to
use double dereferencing.
Ruben
64\errgw64bmatch2:bmatch2.cpp:405:34: error: request for member 'tagName'
in 'piSpecEl', which is of pointer type 'VSEI* {aka __gnu_cxx::__normal_iter
atorSElement*, std::vectorSElement *}' (maybe you meant to use '-' ?)
64\errgw64bmatch2:bmatch2.cpp:406:37: error: request for member
'lsAttributes' in 'piSpecEl', which is of pointer type 'VSEI* {aka
__gnu_cxx::__normal
_iteratorSElement*, std::vectorSElement *}' (maybe you meant to use
'-' ?)
64\errgw64bmatch2:bmatch2.cpp:407:36: error: request for member
'lsAttributes' in 'piSpecEl', which is of pointer type 'VSEI* {aka
__gnu_cxx::__normal
_iteratorSElement*, std::vectorSElement *}' (maybe you meant to use
'-' ?)
64\errgw64bmatch2:bmatch2.cpp:409:32: error: request for member 'name' in
'piSpecAttrib', which is of pointer type 'LSAI* {aka std::_List_iteratorSAt
tribute*}' (maybe you meant to use '-' ?)
From: Ruben Van Boxem vanboxem.ru...@gmail.com
To: mingw-w64-public@lists.sourceforge.net
Sent: Monday, November 5, 2012 11:52 PM
Subject: Re: [Mingw-w64-public] bug in gcc? has nothing defined for
iterator references
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
()-SElement::lsAttributes.std::list_Tp,
_Alloc::beginstd::basic_stringchar,
std::allocatorstd::basic_stringchar ()'
32\errgw32bmatch2:bmatch2.cpp:404:93: error: no match for 'operator!='
in 'iSpecAttrib != ( iSpecEl)-__gnu_cxx::__normal_iterator_Iterator,
_Container::operator-SElement*, std::vectorSElement
()-SElement::lsAttributes.std::list_Tp,
_Alloc::endstd::basic_stringchar,
std::allocatorstd::basic_stringchar ()'
typedef struct {
Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)
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] RFC: How shall we plan releases of new major versions?
On 11/6/2012 16:57, JonY wrote:
Actually, according to
http://msdn.microsoft.com/en-us/library/28d5ce15%28v=vs.80%29.aspx
In Visual C++ 2005, vswprintf conforms to the ISO C Standard, which
requires the second parameter, count, of type size_t. To force the old
nonstandard behavior, define _CRT_NON_CONFORMING_SWPRINTFS. The old
behavior may not be in a future version, so code should be changed to
use the new conformant behavior.
We do that to mingw-w64 too? MSVC has this behavior since 2005.
Obviously it will break if user defines _CRT_NON_CONFORMING_SWPRINTFS
and C++11 at the same time, but that would be PEBCAK.
Alright new patch attached.
Tested with _CRT_NON_CONFORMING_SWPRINTFS and __USE_MINGW_ANSI_STDIO on
and off.
Comments?
Index: stdio.h
===
--- stdio.h (revision 5439)
+++ stdio.h (working copy)
@@ -632,6 +632,10 @@
#define __mingw_ovr static __cdecl
#endif
+#if defined(_CRT_NON_CONFORMING_SWPRINTFS) defined(__cplusplus)
(__cplusplus = 201103L)
+#error _CRT_NON_CONFORMING_SWPRINTFS cannot be used with C++11 or later.
+#endif /* defined(_CRT_NON_CONFORMING_SWPRINTFS) defined(__cplusplus)
(__cplusplus = 201103L) */
+
#if __USE_MINGW_ANSI_STDIO
/*
* User has expressed a preference for C99 conformance...
@@ -742,8 +746,7 @@
return __mingw_vwprintf( __format, __local_argv );
}
-/* For libstdc++ */
-#if defined(__cplusplus) (__cplusplus = 201103L)
!defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF)
+#if !defined(_CRT_NON_CONFORMING_SWPRINTFS)
__mingw_ovr
/* __attribute__((__format__ (gnu_wprintf, 3, 0))) */ __MINGW_ATTRIB_NONNULL(3)
int vswprintf (wchar_t *__stream, size_t __n, const wchar_t *__format,
__builtin_va_list __local_argv)
@@ -757,7 +760,7 @@
{
return __mingw_vswprintf( __stream, __format, __local_argv );
}
-#endif /* defined(__cplusplus) (__cplusplus = 201103L)
!defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF) */
+#endif /* !defined(_CRT_NON_CONFORMING_SWPRINTFS) */
#ifndef __NO_ISOCEXT /* externs in libmingwex.a */
__mingw_ovr
@@ -816,7 +819,9 @@
int __cdecl vfwprintf(FILE * __restrict__ _File,const wchar_t * __restrict__
_Format,va_list _ArgList);
int __cdecl vwprintf(const wchar_t * __restrict__ _Format,va_list _ArgList);
_CRTIMP int __cdecl swprintf(wchar_t * __restrict__ , const wchar_t *
__restrict__ , ...) __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
+#if defined(_CRT_NON_CONFORMING_SWPRINTFS)
_CRTIMP int __cdecl vswprintf(wchar_t * __restrict__ , const wchar_t *
__restrict__ ,va_list) __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
+#endif /*!_CRT_NON_CONFORMING_SWPRINTFS*/
#endif /* __USE_MINGW_ANSI_STDIO */
#ifndef WEOF
@@ -850,6 +855,11 @@
_CRTIMP int __cdecl _snwprintf(wchar_t * __restrict__ _Dest,size_t
_Count,const wchar_t * __restrict__ _Format,...)
__MINGW_ATTRIB_DEPRECATED_SEC_WARN;
_CRTIMP int __cdecl _vsnwprintf(wchar_t * __restrict__ _Dest,size_t
_Count,const wchar_t * __restrict__ _Format,va_list _Args)
__MINGW_ATTRIB_DEPRECATED_SEC_WARN;
+#if !defined(_CRT_NON_CONFORMING_SWPRINTFS) !defined(__USE_MINGW_ANSI_STDIO)
+ __mingw_ovr int __cdecl vswprintf(wchar_t * __restrict__ _Dest,size_t
_Count,const wchar_t * __restrict__ _Format,va_list _Args)
__MINGW_ATTRIB_DEPRECATED_SEC_WARN{
+return _vsnwprintf(_Dest,_Count,_Format,_Args);
+ }
+#endif /* !defined(_CRT_NON_CONFORMING_SWPRINTFS) */
#ifndef __NO_ISOCEXT /* externs in libmingwex.a */
#if !defined (__USE_MINGW_ANSI_STDIO) || __USE_MINGW_ANSI_STDIO == 0
@@ -913,7 +923,6 @@
#ifdef _CRT_NON_CONFORMING_SWPRINTFS
#ifndef __cplusplus
#define swprintf _swprintf
-#define vswprintf _vswprintf
#define _swprintf_l __swprintf_l
#define _vswprintf_l __vswprintf_l
#endif
Index: wchar.h
===
--- wchar.h (revision 5439)
+++ wchar.h (working copy)
@@ -458,6 +458,10 @@
#define __mingw_ovr static __cdecl
#endif
+#if defined(_CRT_NON_CONFORMING_SWPRINTFS) defined(__cplusplus)
(__cplusplus = 201103L)
+#error _CRT_NON_CONFORMING_SWPRINTFS cannot be used with C++11 or later.
+#endif /* defined(_CRT_NON_CONFORMING_SWPRINTFS) defined(__cplusplus)
(__cplusplus = 201103L) */
+
#if __USE_MINGW_ANSI_STDIO
/*
@@ -568,8 +572,7 @@
return __mingw_vwprintf( __format, __local_argv );
}
-/* For libstdc++ */
-#if defined(__cplusplus) (__cplusplus = 201103L)
!defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF)
+#if !defined(_CRT_NON_CONFORMING_SWPRINTFS)
__mingw_ovr
/* __attribute__((__format__ (gnu_wprintf, 3, 0))) */ __MINGW_ATTRIB_NONNULL(3)
int vswprintf (wchar_t *__stream, size_t __n, const wchar_t *__format,
__builtin_va_list __local_argv)
@@ -583,7 +586,7 @@
{
return __mingw_vswprintf( __stream, __format, __local_argv );
}
-#endif /* defined(__cplusplus) (__cplusplus = 201103L)
!defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF) */
+#endif /* !defined(_CRT_NON_CONFORMING_SWPRINTFS) */
/*#ifndef __NO_ISOCEXT */ /* externs in
Re: [Mingw-w64-public] MinWG64 on Windows, for Windows?
With this in mind, which package should I use to compile on Windows for Linux? You probably see it coming… which package should I use to compile on Windows for MacOSX? In another words, what solution is there to cross compile on Windows, for Windows, Linux and MacOSX? have a look at crosstool-ng http://crosstool-ng.org/. coupled with Cygwin http://cygwin.com/ on Windows, it should allow all kinds of cross-compilation. just make sure you're patient enough while Cygwin builds the cross-compilers; might take a few hours... ;) Zouzou -- 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] MinWG64 on Windows, for Windows?
On Tue, Nov 6, 2012 at 6:50 AM, Zouzou wrote: With this in mind, which package should I use to compile on Windows for Linux? You probably see it coming… which package should I use to compile on Windows for MacOSX? In another words, what solution is there to cross compile on Windows, for Windows, Linux and MacOSX? have a look at crosstool-ng http://crosstool-ng.org/. coupled with Cygwin http://cygwin.com/ on Windows, it should allow all kinds of cross-compilation. just make sure you're patient enough while Cygwin builds the cross-compilers; might take a few hours... ;) Or if you want a bit faster cross compiler system use MSYS and mingw-w64 distributed binaries. There is no need to encumber the extra time the Cygwin runtime would add to the process. -- 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)
On Tue, Nov 6, 2012 at 5:04 AM, Václav Šmilauer e...@doxos.eu 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] bug in gcc? dereferencing pointers to iterators
Hi Jim! A gentle suggestion ... On Tue, Nov 6, 2012 at 5:03 AM, Jim Michaels jmich...@yahoo.com wrote: somehow I think pointers are the way to go when modifying an iterator function argument. but I am having problems. I have a pointer to an iterator. ... Many (by no means all) of your questions are about c++, rather than gcc or even more specifically mingw-w64. You will generally get more useful and detailed answers to such questions on one of the c++ news groups. You'll also be helping out others who read those groups (and don't follow this list) who might learn something from the discussions. comp.lang.c++ is an unmoderated group, and is quite good (although it can be a little noisy at times, and sometimes the commentary gets snarky). comp.lang.c++.moderated is similar, but, well, moderated. The discussions are also quite good, but the turn-around is a little slower due to the moderation. One way to see whether your question is specific to mingw-w64 would be to try compiling with another compiler. For example, if you see the same issue compiling with gcc on unix (or cygwin), then it's probably a c++ issue rather than a mingw-w64 issue (although it could be a gcc issue). For compile time issues, you can also try the Comeau online compiler: www.comeaucomputing.com/tryitout/ That could help you distinguish between a c++ issue, and a gcc (or mingw-w64) issue. Of course, you can browse those news groups in advance of posting anything to see whether you like their culture and whether they might be useful to you ... - Jim Michaels ... Happy Hacking! K. Frank -- 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] bug in gcc? dereferencing pointers to iterators
On Tue, Nov 6, 2012 at 8:55 AM, K. Frank wrote: Hi Jim! A gentle suggestion ... Oh, don't be too gentle. ;D On Tue, Nov 6, 2012 at 5:03 AM, Jim Michaels wrote: somehow I think pointers are the way to go when modifying an iterator function argument. but I am having problems. I have a pointer to an iterator. ... Many (by no means all) of your questions are about c++, rather than gcc or even more specifically mingw-w64. You will generally get more useful and detailed answers to such questions on one of the c++ news groups. You'll also be helping out others who read those groups (and don't follow this list) who might learn something from the discussions. I was wondering how long it was going to take before someone was going to suggest this. Longer than I thought it would. :D -- 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] bug in gcc? dereferencing pointers to iterators
2012/11/6 Earnie Boyd ear...@users.sourceforge.net On Tue, Nov 6, 2012 at 8:55 AM, K. Frank wrote: Hi Jim! A gentle suggestion ... Oh, don't be too gentle. ;D On Tue, Nov 6, 2012 at 5:03 AM, Jim Michaels wrote: somehow I think pointers are the way to go when modifying an iterator function argument. but I am having problems. I have a pointer to an iterator. ... Many (by no means all) of your questions are about c++, rather than gcc or even more specifically mingw-w64. You will generally get more useful and detailed answers to such questions on one of the c++ news groups. You'll also be helping out others who read those groups (and don't follow this list) who might learn something from the discussions. I was wondering how long it was going to take before someone was going to suggest this. Longer than I thought it would. :D He wasn't the first one: http://sourceforge.net/mailarchive/message.php?msg_id=29181200 and I wasn't so gentle there. I'm sure you can dig up countless other change how c++ works requests... I even tried pointing him to some good books, but alas... http://sourceforge.net/mailarchive/message.php?msg_id=28990892 One stop shop for basic C++ questions like these: stackoverflow.com. Ruben -- 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 -- 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
