Re: [Mingw-w64-public] bug in gcc? dereferencing pointers to iterators

2012-11-06 Thread Ruben Van Boxem 
2012/11/6 Earnie Boyd 

> 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

Re: [Mingw-w64-public] bug in gcc? dereferencing pointers to iterators

2012-11-06 Thread Earnie Boyd 
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-06 Thread K. Frank 
Hi Jim!

A gentle suggestion ...

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.

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] Error building python extension (DLL load failed: invalid access to memory location)

2012-11-06 Thread 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] MinWG64 on Windows, for Windows?

2012-11-06 Thread Earnie Boyd 
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 . coupled with
> Cygwin  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] MinWG64 on Windows, for Windows?

2012-11-06 Thread Zouzou 
> 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 . coupled with 
Cygwin  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] RFC: How shall we plan releases of new major versions?

2012-11-06 Thread JonY 
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_CONFORM

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

2012-11-06 Thread 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] bug in gcc? dereferencing pointers to iterators

2012-11-06 Thread Ruben Van Boxem 
Op 6 nov. 2012 11:04 schreef "Jim Michaels"  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::list LSA;
> typedef  std::list::iterator LSAI;
> typedef  std::list LS;
> typedef  std::list::iterator LSI;
> LSA lsGlobalIDs;
>
> typedef std::vector 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  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::vector VSE;
> typedef std::vector::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
> ator >*}' (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
> _iterator >*}' (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
> _iterator >*}' (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_iterator tribute>*}' (maybe you meant to use '->' ?)
>
>
>
>
>> 
>> From: Ruben Van Boxem 
>> 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"  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::allocator > >()'
>> >
>> > 32\errgw32bmatch2:bmatch2.cpp:404:93: error: no match for 'operator!='
in 'iSpecAttrib != (& iSpecEl)->__gnu_cxx::__normal_iterator<_Iterator,
_Container>::operator->
>()->SElement::lsAttributes.std::list<_Tp,
_Alloc>::end,
std::allocator > >()'
>> >
>> > typedef struct {
>> > std::string
>> > name,
>> > val;
>> > bool isBoolean;
>> > VUI hitLineNumbers;
>> > } SAttribute;
>> > typedef  std::list LSA;
>> > typedef  std::list::iterator LSAI;
>> >
>> > boo

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

2012-11-06 Thread Jim Michaels 
that would be nice...




>
> From: Yves 
>To: "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  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  wrote:
>>
>>
>>2012/11/2 Yves Perron 
>>>
>>>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 , 
>>>std::to_string, and ) you will find GCC's libstdc++ unfortunately 
>>>lacking. Everything else is usually implemented better than on MSVC though, 
>>>including .
>>>
>>>To use CMake, just be sure "g++" is in PATH, and run
>>>cmake path/to/source -G"MinGW 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
Aut

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

2012-11-06 Thread 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] bug in gcc? dereferencing pointers to iterators

2012-11-06 Thread Jim Michaels 
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::list LSA;
typedef  std::list::iterator LSAI;
typedef  std::list LS;
typedef  std::list::iterator LSI;
LSA lsGlobalIDs;

typedef std::vector 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  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::vector VSE;
typedef std::vector::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
ator >*}' (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
_iterator >*}' (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
_iterator >*}' (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_iterator*}' (maybe you meant to use '->' ?)







>
> From: Ruben Van Boxem 
>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"  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::allocator > >()'
>>
>> 32\errgw32bmatch2:bmatch2.cpp:404:93: error: no match for 'operator!=' in 
>> 'iSpecAttrib != (& iSpecEl)->__gnu_cxx::__normal_iterator<_Iterator, 
>> _Container>::operator-> 
>> >()->SElement::lsAttributes.std::list<_Tp, 
>> _Alloc>::end, std::allocator 
>> > >()'
>>
>> typedef struct {
>>     std::string
>>     name,
>>     val;
>>     bool isBoolean;
>>     VUI hitLineNumbers;
>> } SAttribute;
>> typedef  std::list LSA;
>> typedef  std::list::iterator LSAI;
>>
>> bool attribNameIsInSpecElement(std::string tagName, std::string attrib, 
>> VSEI& iSpecEl, LSAI& iSpecAttrib, bool isXHTML, bool isXML) {
>Why are you passing the iterator references into the function when you set 
>them below anyway? Remove these function parameters, and make the variables 
>local to their for loop.
>>     for (iSpecEl=vseSpecElements.begin(); iSpecEl != vseSpecElements.end(); 
>> iSpecEl++) {
>>

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

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