Re: [Mingw-w64-public] Semi-OT: Is this sourceforge email legit? (Fwd: Important Account Information - Reconfirm Mailing List Subscriptions)

[K. Frank]

Hi Kai!

On Fri, Jun 9, 2017 at 4:27 AM, Kai Tietz via Mingw-w64-public
<mingw-w64-public@lists.sourceforge.net> wrote:
> Hello,
>
> yes, everybody seems to get such a mail for the subscribed sf public
> mailing lists.  SF changed describes the reasoning at
> https://sourceforge.net/blog/sourceforge-project-e-mail-policy-update/
> for further information.

Thanks for the clarification / confirmation.  I'll treat the sourceforge
email as legitimate.

> Regards,
> Kai


Best.


K. Frank


> 2017-06-09 7:26 GMT+02:00 LRN <le...@something.com>:
>> On 6/9/2017 6:13 AM, K. Frank wrote:
>>> Hello List!
>>>
>>> I just wanted to check whether this email from sourceforge is legit.
>>> It seemed a little odd -- out of the blue -- and sourceforge has earned
>>> itself an imperfect reputation.
>>>
>>> Is this okay?  Have others got this?
>>> ...

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Semi-OT: Is this sourceforge email legit? (Fwd: Important Account Information - Reconfirm Mailing List Subscriptions)

[K. Frank]

Hello List!

I just wanted to check whether this email from sourceforge is legit.
It seemed a little odd -- out of the blue -- and sourceforge has earned
itself an imperfect reputation.

Is this okay?  Have others got this?


Thanks.


K. Frank


-- Forwarded message --
From: SourceForge.net <noti...@slashdotmedia.com>
Date: Thu, Jun 8, 2017 at 6:34 PM
Subject: Important Account Information - Reconfirm Mailing List Subscriptions
To: 


Hi K. Frank,

Thanks for being a SourceForge user. Our records indicate that you are
subscribed to the following project mailing lists:

...
mingw-w64-public
...

We are contacting you to confirm you are still interested in receiving
emails from these SourceForge project lists.  If you do not confirm
your subscriptions by June 29th, you will be unsubscribed from the
above mailing lists.

Please click here to confirm your subscriptions:

https://sourceforge.net/mailman/reconfirm ...

...

Thanks,
The SourceForge Team
A Slashdot Media Company

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Wrong quotient results of `remquo()`?

[K. Frank]

Hello Lefty!

I do think you have found a bug here, and it does appear to
be in the mingw-w64 code.  Disclaimer: I don't understand
this completely.

Further comments in line, below.


On Tue, Sep 6, 2016 at 11:52 PM, lhmouse <lh_mo...@126.com> wrote:
> More likely a bug in mingw-w64:
>
> #include 
> #include 
> volatile double x = 10.001000, y = -1.299000;
> int main(){
> int quo;
> double rem = remquo(x, y, );
> printf("rem = %f, quo = %d\n", rem, quo);
> }
>
> With mingw-w64 this program gives the following output:
>
> E:\Desktop>gcc test.c
>
> E:\Desktop>a
> rem = -0.391000, quo = 0

I get the same result as you in a c++ test program using:

   g++ (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 4.9.2

> However, according to ISO C11 draft:
>
>> 7.12.10.3 The remquo functions
>> 2 The remquo functions compute the same remainder as the remainder 
>> functions. In
>> the object pointed to by quo they store a value whose sign is the sign of 
>> x/y and whose
>> magnitude is congruent modulo 2n to the magnitude of the integral quotient 
>> of x/y, where
>> n is an implementation-defined integer greater than or equal to 3.
>
> the value stored in `quo` must have the same sign with `x/y`.
>
> In the above example, since `x/y`, which is about -7.699, is negative,
> returning a non-negative value (zero in the above example) should be a bug.

I agree with lh_mouse's reading of the standard, and that
quo should be negative to match the sign of x / y.

Here is my imperfect analysis of what is going on.

First, I found a copy of remquo.S here:

   
https://sourceforge.net/p/mingw-w64/code/6570/tree//stable/v1.x/mingw-w64-crt/math/remquo.S

(but I don't understand it).

I also found a "softmath" copy of remquo.c here:

   
https://github.com/msys2/mingw-w64/blob/master/mingw-w64-crt/math/softmath/remquo.c

(I have no idea whether remquo.c is equivalent in detail to
remquo.S.)


   #include "softmath_private.h"

   double remquo(double x, double y, int *quo)
   {
   double r;

   if (isnan(x) || isnan(y)) return NAN;
   if (y == 0.0)
   {
   errno = EDOM;
   __mingw_raise_matherr (_DOMAIN, "remquo", x, y, NAN);
   return NAN;
   }

   r = remainder(x, y);
   if (quo) *quo = (int)((x - r) / y) % 8;
   return r;
   }


First, the expression "(int)((x - r) / y)" is undefined
behavior when (x - r) / y is too large for an int.  (This
can easily happen with floats and doubles.)  (remquo.S
uses the intel floating-point instruction fprem1, and
therefore -- if written correctly -- should not have this
problem.)

But ignoring the possible integer overflow, the error here,
which is the result lh_mouse gets in his test, is that if

   (int)((x - r) / y)

is a multiple of 8, then

  (int)((x - r) / y) % 8

will evaluate to zero, losing the sign information.

In lh_mouse's test case

   x / y = -7.699

which rounds-to-nearest to -8, which equals 0 mod 8.

How might one fix this (in c code)?  My reading of the
standard says that quo doesn't have to be exactly the
last three bits -- or even the last n bits -- of

   (int)((x - r) / y)

Rather, it only has to be congruent to this mod 8.

So (ignoring overflow in the integer conversion), one
could do something like this:

r = remainder(x, y);
if (quo) *quo = (int)((x - r) / y) % 8;
if (quo  &&  *quo == 0  &&  x/y < 0.0)  *quo = -16;
return r;

(Here, we are deeming the sign of 0 to be positive.  I don't
know whether this would be language-lawyer consistent with
the standard, but for two's-complement integers, zero does
have the "positive" sign bit.)

The core problem is that the integer quotient could be a
large, negative multiple of 8 (and not even fit in an int).
In such a case, quo has to preserve the sign of x/y, so it
can't be 0. but there's no obvious favored (congruent mod 8)
approximation to x/y (other than 0, which we can't use), so
you might as well just use -16.

Should you also use +16 for quo when x/y is a positive
multiple of 8?  My reading of the standard says that you
could, but that seems a little weird to me, so maybe 0
is more natural in the positive case.

A couple of cautions:  I have no idea whether remquo.S
behaves the same way as remquo.c.  However, remquo.c
does give the same incorrect value (0) for quo that
lh_mouse reports and that I see in my test.  Also, I
assume that my test program ends up using remquo.S,
but I really haven't any idea how to check this.

In any event, remquo.c (at least the version I found
on line) is wrong on two counts -- it shows the bug
lh_mouse found, and it can have undefined behavior in
the integer conversion.

My guess is that lh_mouse's test and mine both end up
using remquo.S (Why 

Re: [Mingw-w64-public] winpthreads, pthread_setschedparam, and detached threads

[K. Frank]

Hello Lefty!

On Tue, May 31, 2016 at 11:31 PM, lh mouse  wrote:
> Note that in most cases threads other than the one calling `pthread_detach()` 
> can terminate at anytime.
> ...

I would say your description fits the typical use case.

> By calling `pthread_detach()` on a `pthread_t` you _semantically_ 
> destroy/close it and should not use it any more.

Well, maybe.  I certainly don't find anything in the pthread standard that
justifies this semantic interpretation (nor that contradicts it).  I do expect
that many people look at it the way you do.

One can certainly imagine a use case where "using" a detached thread (and
calling pthread_setschedparam() on it) would make sense.  Detached threads
still respect synchronization objects (e.g., mutexes and condition variable, but
not pthread_join).  So maybe you have a detached thread servicing some sort
of queue (controlled by a condition variable) and you want to throttle it by
changing its priority, so you want to call pthread_setschedparam() on it.

Of course, you can easily work around this issue by not detaching the thread.

>
> Best regards,
> lh_mouse
> 2016-06-01


Happy Hacking!


> 发件人："Burkhardt, Glenn BUTAS" 
> ...
> 主题：[Mingw-w64-public] winpthreads, pthread_setschedparam,
> and detached threads
>
> The way the winpthreads code is writing, the Windows handle for the thread is 
> cleared when the thread is made detached.  That means that the 
> pthread_setschedparam() call can't work.  So thread priorities for detached 
> threads can only be set once, at thread creation, before the thread is 
> detached, or as part of the pthread_create() call.
> ...

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads, pthread_setschedparam, and detached threads

[K. Frank]

Hi Glenn!

On Tue, May 31, 2016 at 11:11 AM, Burkhardt, Glenn BUTAS
<glenn.burkha...@utas.utc.com> wrote:
> The way the winpthreads code is writing, the Windows handle for the thread is 
> cleared when the thread is made detached.  That means that the 
> pthread_setschedparam() call can't work.  So thread priorities for detached 
> threads can only be set once, at thread creation, before the thread is 
> detached, or as part of the pthread_create() call.
>
> Is there a reason for this?  For me, it's unexpected behavior.

I don't see anything in the pthreads documentation that makes clear
whether this should be allowed or not.  However, the error-code return
values for pthread_setschedparam() does not list an error value for
this situation, which perhaps is a hint that it should work.

On the other hand, there does seem to be precedent for this not working.

I found some documentation for DEC / VMS pthreads here:

   http://www.mi.infn.it/~calcolo/OpenVMS/ssb71/6493/6493p002.htm

Quoting from paragraph 2.3.4:

   It is illegal for your program to attempt any operation on a detached
   thread or to use any information in the thread object associated with
   a detached thread. For instance, a thread cannot join on a detached
   thread, and your program cannot cancel a detached thread.

So it sounds like the VMS implementation, at least, doesn't support calling
pthread_setschedparam() on a detached thread.

(I wonder if a detached thread calling pthread_setschedparam() on itself
could be an edge case in some implementations.)


Happy Hacking!


K. Frank

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[K. Frank]

Hi Benjamin!

On Thu, Mar 17, 2016 at 4:07 AM, Benjamin Bihler
<benjamin.bih...@compositence.de> wrote:
> Thank you for the suggestion.
>
> I have tried the following code snippets when the program starts up to set 
> the floating-point precision:
>
> ---
> unsigned int fpu_cw;
>  _controlfp_s(_cw, _PC_24, _MCW_PC);
> ---
> ...
> This does not help. Still the asynchronous thread gives different results. 
> Should I use different commands? Which ones?

I don't know anything about the details of _controlfp_s, etc., but I do
have a debugging question.

Did any of your versions of calling _controlfp_s have any effect in that
they changed the results produced by the main thread (even if those
changed results did not match the results of the asynchronous thread)?

Or did your main thread still give the same results as without the _controlfp_s
call?

Obviously, until you can change the behavior of the main thread, you can't
change it to match the asynchronous threads.

In any event, hopefully someone on this list could tell you what call to
_controlfp_s you need to match the floating-point environment that is
getting set up for the asynchronous thread.  (I certainly can't.)

> Actually limiting the fp precision on the main thread would be a solution for 
> me, though it feels like a dirty workaround.

Yeah, you shouldn't have to use the less-favorable precision.  But that's
the nature of work-arounds ...

Logically, I do think the idea should work.  Sorry i can't give you any
detail on how to make it work.

(Of course, the better approach is to figure out how to make the child
threads behave -- i.e., use the extended precision, and otherwise use
a floating-point environment consistent with that of the main thread.)


Good luck.


K. Frank

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[K. Frank]

Hi Benjamin!

I have no idea how to patch mingw-w64 to do you you really want,
but perhaps I have a suggestion for a work-around, below.

On Tue, Mar 15, 2016 at 11:15 AM, Benjamin Bihler
<benjamin.bih...@compositence.de> wrote:
> I have taken commit d82c6defa723b6e7986091ce0fb74da544b9e0f6 ("Reset thread 
> floating point settings on new thread") from the master branch of the mingw64 
> repository, compiled it and replaced the respective files in the "include" 
> and "lib" folder of the "x86_64-mingw32" folder of my mingww64 5.3.0 
> installation with the newly compiled files.
>
> Then I have compiled my sample file with this modified mingw64 installation. 
> It had no effect, the two threads give different results. I have checked that 
> the executable depends only on the DLLs Kernel32.dll and Msvcrt.dll.
>
> When I add
>
> _fpreset()
>
> as the first command of the method that is run asynchronously, both threads 
> give the same result. But this has already been the case with the unmodified 
> mingw64 compiler (without overwriting the link binaries with those from the 
> new revision), I have checked that.
>
> My sample is a C++ sample, since I am using the gnu++11 features.
>
> It would be painful for me, if I had to add _fpreset() to all methods that I 
> want to run asynchronously, especially since they may be part of other 
> libraries.
>
> Did I patch my mingw64 installation in a wrong way? Otherwise it seems as if 
> the commit mentioned above does not solve my problem.
>
> Does anyone have another idea? Thanks!

Disclaimer: I don't know anything about the patch or the _fpreset()
call.  Also, I am speaking from memory, so I may have some of
the details backwards.

Is it essential that you get the better, 80-bit long-double behavior,
or can you live with 64-bit long doubles as long as all threads
behave the same way?

As I understand it, the main thread starts with the 80-bit setting,
but somebody (mingw?, microsoft?) sets 64-bit behavior on
start-up of subsequent threads.

Perhaps you could -- just once, in your main thread -- set the
64-bit behavior when your program starts up.  Then (hopefully)
all new threads that automatically get 64-bit behavior will match
your main thread.

You would still have to call some sort of "_fpset(...)" once in
your main thread, but you would no longer have to add _fpreset
to all of your asynchronous methods.

(You might have to do some reverse engineering or ask on this
list to find out exactly what floating-point mode you need to set
for your main thread in order that it match that of the child treads.)

Sorry if this is all nonsense, but maybe it could help.


Good luck.


K. Frank

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[K. Frank]

uot;floating-point
environment" is set differently for different threads is correct.  This seems
wrong to me, but I have a vague recollection that in an earlier discussion
an arguably legitimate reason for this was put forth.)

> On Tue, Mar 1, 2016 at 9:04 AM, Benjamin Bihler
> <benjamin.bih...@compositence.de> wrote:
>>
>> Hello,
>>
>> I have found a behaviour of MinGW-W64 5.3.0 that disturbs me very much:
>> the results of floating-point operations may differ, if they are run on
>> different threads.
>> ...
> --
> Daniel


Happy Floating-Point Hacking!


K. Frank

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] SEMI-OT: Images of 3d-rotated objects

[K. Frank]

Hello List!

Well, to make this a little bit on topic, I want to do this with mingw-w64 c++.

Let's say I have somehow constructed an image on the surface of a sphere
(or cylinder, or egg-shape, etc.).  I would like to be able to rotate
this sphere
(together with its surface image), and then generate a two-dimensional image
of the rotated sphere.

I would like to be able to do it in my c++ code, but generating such images
in a free-standing app and then loading them into my program could also be
acceptable.

I am looking for a quick-and-dirty solution (and am happy to write
quick-and-dirty
code), so installing a large, complicated image-processing tool (and
learning how
to use it) or building a large, complicated image-processing library
(and learning
how to use it) would have undesirable overhead.  I don't need or want
to do anything
fancy, so I don't need the power of a sophisticated tool -- I just
want to be able to
do my (relatively) simple task quickly.

I do already use Qt (version 4), so I would not consider a Qt-based solution to
entail installing / building a large, complicated library.

Any suggestions would be welcome.  Again, I have a strong preference for being
able to do this in my own (mingw-w64-compatible) code.


Thanks in advance for any ideas.


K. Frank

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Latest mingw-w64-install broken on all Window versions

[K. Frank]

Hello Edward!

On Wed, Aug 5, 2015 at 10:35 AM, Edward Diener
eldlistmaili...@tropicsoft.com wrote:
 The latest mingw-w64-install program is broken on all Window versions (
 Vista, 7, 8.1 ) in which I tried to use it.

I had a similar problem back in November in that the installer
didn't work (on 64-bit windows 7).  I don't remember the details.

 ...
 Since the install is totally broken for now, where do I go to manually
 download and install the releases I want ? I looked under SourceForge
 Files for mingw-64 but could not find the releases there.

If you want posix threads and SEH exceptions, one possibility
for the latest and greatest would be the compressed file:

   x86_64-5.1.0-release-posix-seh-rt_v4-rev0.7z

downloadable from the sourceforge folder with url:

   
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/5.1.0/threads-posix/seh/

I did the equivalent back in November for the 4.9.2 version.
(Note, I haven't actually used the 5.1.0 version, but I assume
that it works.)

There are other possibilities (different builds, different
configuration choices): see the sourceforge folder:

   
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/

You could follow, for example, the mingw-builds link there
and pick your desired configuration / version as you navigate
down to the downloadable file.


Happy 64-bit g++ Hacking!


K. Frank

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Winpthreads slow mutexes - still applies?

[K. Frank]

Hi Mattias!

On Sat, Jun 20, 2015 at 4:32 AM, Mattias Engdegård matti...@acm.org wrote:
 19 jun 2015 kl. 23.12 skrev Alexandre Pereira Nunes 
 alexandre.nu...@gmail.com:

 I came across this: https://sourceforge.net/p/mingw-w64/bugs/344/

 Does anyone knows if that's still the case?

 Yes. There is a patch, but it has not been cleared for release yet. It may 
 take a few weeks more, given that people are on holiday. I shall try to 
 accelerate the process.
 ...

Out of curiosity, do you know what approach the patch takes?
I ask because std::thread supports timed waits on (timed) mutexes,
and I believe that pthreads does as well.  How does the patch
implement timed waits?

Quoting from the bug report cited above:

   Currently libwinpthread implements mutexes directly on top
   of Windows semaphores. Semaphores, being kernel objects,
   require kernel mode transition in order to lock or unlock, which
   is very slow compared to interlocked operations (as in, up to
   several hundred times slower).

   Suggestion: either base mutexes on Windows critical sections
   outright, or do the same thing manually.

If the solution is to base winpthread's mutexes on windows
critical sections, you will have to address the issue of timed
waits.  I believe that windows critical sections offer no timed
wait functionality.

I see three ways to address this.  Use critical sections as mutexes,
but add additional helper objects (that support waits) to any timed
wait call.  I think this is doable, but seems unattractively complicated
and will worsen performance.

Write from scratch (i.e. don't use windows critical sections) your
own mutexes that support timed waits.  This ought to be doable,
but would be some work and does seem like reinventing the wheel.
(But, as I understand it, winpthread did write its own condition
variables from scratch.)

Recognize that std::thread (I don't know if this applies to pthreads
or not) distinguishes between timed mutexes (that you can perform
a timed wait on) and regular mutexes that do not support timed
waits.  In this case you could, for example, base regular mutexes
on windows critical sections (no timed waits), and timed mutexes
on windows semaphores (or windows mutexes).  This has the
disadvantage that you now have two different kinds of mutexes.
(Why shouldn't you be able to perform a timed wait on any mutex?),
but the regular mutexes should now be faster.

I should note that both windows semaphores and windows mutexes
(Both support timed waits.) are cross-process synchronization
objects, whereas windows critical sections can only be used to
synchronize threads within a single process (consistent with the
single-process threading model supported by std::thread and
pthreads).  As cross-process objects they are heavier weight and
less efficient, and this probably accounts for the mutex inefficiency
described in the bug report.


Best.


K. Frank

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Native Win32 std::thread

[K. Frank]

Hello Marco (and Ruben  Friends)!

On Sun, Mar 8, 2015 at 7:20 AM, Marco Costalba mcosta...@gmail.com wrote:
 I am one of the developer of a chess engine called Stockfish:

 https://github.com/official-stockfish/Stockfish

 A chess engine is a high performance piece of multi-thread software, where
 even a small sub-optimal code path immediately translates in a sensible slow
 down.
 ...
 Recently we started to switch to C++11 for various reasons, but especially
 due to library support for std::thread and friends. This allows us to
 greatly simplify the code and getting rid of all the platform specific
 wrappers.

 While on Linux and on MSVC 2013 we have similar performance between C++11
 and C++03 versions, under Windows with mingw there is a huge performance gap
 when run in SMP mode (around 30% slower), when we run in single thread mode
 speed is similar. This is particularly unfortunate because our release
 version is compiled with gcc for all the platforms because currently gcc
 gives the best speed.

 After some analysis we realized the speed difference is all due to thread
 library implementation on mingw that is based on POSIX instead of native
 Win32 threads.
 ...
 So I would like to ask:

 1. There exists somewhere a mingw-w64 build supporting native win32
 std::thread?

 2. There is some plan to develop it?

I can give you some historical background.  Please note, this is now
several years out of date.

Here is a thread on some experimental work I did on a semi-native
std::thread implementation:

   http://comments.gmane.org/gmane.comp.gnu.mingw.w64.general/2091

Here is some (out-of-date and unrealistic) timing information:

   http://comments.gmane.org/gmane.comp.gnu.mingw.w64.general/3550

Note that in these timings (unrealistic use cases), mutex contention
was much, much worse in the winpthreads implementation than in the
semi-native implementation, while condition variables were significantly
better. (This appears consistent with the mutex slowdown you noticed.)

Here is a stackoverflow thread touching on some of the same issues:

   http://stackoverflow.com/questions/19250008/mingw-stdthread-with-windows-api

Historically, I think the following considerations entered into mingw-w64's
choices for implementing std::thread:

1)  Support for pre-Vista rules out using windows CONDITION_VARIABLES.

2)  Although not part of standard C++ (nor C), and not part of windows,
pthreads is the posix standard, and therefore important to support.  It
therefore makes sense to build std::thread on top of pthreads (avoiding
duplicative effort and easing mixing of pthreads code with std::thread code),
although this is not a firm requirement.

3)  Licensing concerns and the the fact that an integral value is the de
facto standard (but not part of the posix requirement) for a pthreads handle
led to the development of winpthreads.

One would expect to be able to make std::thread faster by dropping
support for older versions of windows and by not basing std::thread
on winpthreads, but it seems like either of these two changes would
be giving up too much.

On the other hand (but I can't speak for the mingw-w64 team), I would
think that suggestions for improvements in winpthreads -- that would
then lead to greater std::thread efficiency -- would be very welcome
here.

 Thanks for your help and support

 Marco


Happy Multi-Threaded Hacking!


K. Frank

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] gfortran, open mp and floating point precision

[K. Frank]

Hi Carl (and Pieter)!

On Mon, Feb 2, 2015 at 5:29 PM, Carl Kleffner cmkleff...@gmail.com wrote:
 The Windows ABI - see https://msdn.microsoft.com/en-us/library/ms235286.aspx
 - differes from the
 System V ABI - see http://www.x86-64.org/documentation/abi.pdf.

 MingW-W64 sets the x87 FPU control word register to extended precision. The
 'standard' for Windows however is 'double precision'.  See
 https://msdn.microsoft.com/en-us/library/ms235300.aspx.

 On Windows newly started threads never inherit FPU register settings from
 the master thread and set the FPU registers to the standard value. Thus you
 can have different FPU settings in different threads. OpenBLAS i.e. has some
 extra code to propagate the FPU settings. Look for 'CONSISTENT_FPCSR' at
 https://github.com/xianyi/OpenBLAS.

 Using extended precision with GCC can be tricky:
 https://gcc.gnu.org/wiki/FloatingPointMath and
 https://gcc.gnu.org/wiki/x87note. The latter link describes some gotchas
 when using extended precision with GCC.

Your post jogged my memory about the discussion I thought I
recalled, and I was able to find it.  Indeed, it was a thread on
this list started by you (Carl):

   http://sourceforge.net/p/mingw-w64/mailman/message/3303/

   [Mingw-w64-public] FPU control word on startup
   From: Carl Kleffner cmkleffner@gm... - 2014-11-12 21:00:50

(and subsequent posts).

It does sound like this all could be the cause of Pieter's
thread / precision issue.

 Cheers,

 Carl


Best regards.


K. Frank


 2015-02-02 6:34 GMT+01:00 K. Frank kfrank2...@gmail.com:

 Hi Pieter!

 This could be complete misinformation, or correct but
 not relevant.

 On Thu, Jan 15, 2015 at 12:57 PM,  pbed...@aol.com wrote:
  I wrote a test program in fortran and used gfortran 4.9.2 (tdm64-gcc
  4.9.2)
  ...
  However for extended floating point precision off-diagonal elements of
  the
  identity matrix for thread 0 are  0 with the expected magnitude, for
  threads 1 to 3 they are a factor 1000 (!) larger and moreover identical
  to
  those of the identity matrix in the double floating point precision
  calculation.
  ...
  Where is the error?

 I have a vague recollection of a discussion (probably
 on this list) about start-up code writing the Intel x87
 floating-point control word to the floating-point processor.
 ...

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] gfortran, open mp and floating point precision

[K. Frank]

Hi Pieter!

This could be complete misinformation, or correct but
not relevant.

On Thu, Jan 15, 2015 at 12:57 PM,  pbed...@aol.com wrote:
 I wrote a test program in fortran and used gfortran 4.9.2 (tdm64-gcc 4.9.2)
 ...
 However for extended floating point precision off-diagonal elements of the
 identity matrix for thread 0 are  0 with the expected magnitude, for
 threads 1 to 3 they are a factor 1000 (!) larger and moreover identical to
 those of the identity matrix in the double floating point precision
 calculation.
 ...
 Where is the error?

I have a vague recollection of a discussion (probably
on this list) about start-up code writing the Intel x87
floating-point control word to the floating-point processor.

This was maybe something about setting a mode where
extended precision (80-bit) was degraded to double
precision (64-bit).

If any of this is right (and not just a figment of my imagination),
there was some talk of the floating-point control word start-up
code getting called at thread start-up, so that even if your
own initialization code in your main thread wrote the desired
floating-point control word (e.g., to enable extended precision),
this setting would not apply to other threads because they
would get initialized with some default control word (hypothetically
setting those threads to non-extended double precision).

Again, this is a long shot, but I do seem to recall some discussion
of floating-point control word start-up code from a month or two ago.

 With regards
 Pieter Bedijn - retired scientist and software developer


Good luck.


K. Frank

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MinGW LGPL licensed, header-only std::thread implementation

[K. Frank]

Hello Ruben!

On Thu, Dec 11, 2014 at 2:51 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 Hi guys,

 I'd like to draw your attention to a std::thread implementation written
 without pthreads.

 It seems quite lightweight, and almost too small to be fully compliant.

 If it is at all useful or even completely/nearly bug-free, perhaps it would
 be worth getting this into GCC/libstdc++ mainline, because well, it's not
 that biig really. Not sure how a win32 specific code dump would pass by
 libstdc++ people (they're very, very unfriendly to platform specific code
 due to maintenance).

 Anyways, here it is:
 https://github.com/meganz/mingw-std-threads

Would you happen to know how they implement timed mutex waits?
(I haven't looked through the code yet.)

It seems a little difficult to me to implement std::thread on top windows
threads without writing any real code.  (I do realize that one can put
arbitrary code into headers, but that sort of defeats the purpose of a
header-only library.)

 Ruben


Thanks for drawing our attention to this.


Best.


K. Frank

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] TDM-GCC 4.9.2 released

[K. Frank]

Hi Greg!

I can attempt tp answer your question about
-fno-keep-inline-dllexport.

On Tue, Dec 9, 2014 at 1:29 AM, Greg Jung gvj...@gmail.com wrote:
 Hi John,
   If you would indulge my questions, I am intrigued by the advice re:
 -fno-keep-inline-dllexport flag
 because it mentions wxWidgets which I am trying to incorporate into an
 already-large program.
 Do you know what problem it addresses, is it needed to unclutter a
 namespace?

I've used -fno-keep-inline-dllexport when building Qt with mingw-w64.

The issue was that I would run out of memory when linking QtGui.dll
(or maybe QtCore.dll or maybe both).  The link process would use
in excess of 3 GB.  Running the build with -fno-keep-inline-dllexport
made in possible for me to build Qt on a 4 GB machine.  Linking the
dll was still memory intensive, but less.  I think when using
-fno-keep-inline-dllexport the linking step took 2+ GB of memory.

From John's comment I assume something similar is going on with
wxWidgets.


Good luck.


K. Frank


 ...
 On Mon, Dec 8, 2014 at 7:41 PM, John E. / TDM tdra...@tdragon.net wrote:

 Greetings!

 === TDM-GCC 4.9.2 is now available! ===
 ...
   * Remember to use the -fno-keep-inline-dllexport flag to fix memory
 usage problems when linking DLLs with a large number of inline functions
 (such as wxWidgets).
 ...
 Cheers,
 John E. / TDM

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Wt-interest] Building Wt with mingw-w64 -- prefer Mingw-builds or Win-builds?

[K. Frank]

Hi nixMan!

On Tue, Nov 25, 2014 at 4:55 AM, niXman i.nix...@autistici.org wrote:
 K. Frank 2014-11-24 04:32:
 No, no proxy.  I use a wireless router that provides local, internal
 ip addresses through dhcp, but is seen by the outside world as
 a single ip address (dynamically) assigned by my isp.

 Hmm...

 Please create the bug-ticket:
 http://sourceforge.net/p/mingw-w64/bugs/

The page you link to shows a list of bugs, but I don't see any
way to create a new bug-ticket.  I will point out that I do not
have a sourceforge account (and I don't plan to create one),
so maybe that's why I don't see a new-ticket button some
place.

(If there is a way to create a ticket without a sourceforge
account, I would be happy to do so.)

 But I need you help for fix it.

I would be happy to try to help.  Please let me know if there
are any more tests I can do or if you would like me to try out
a new version.

(Please note, this is in no way urgent for me.  I downloaded
the .7z archive, and that seemed to work just fine, so I don't
think I need the installer for anything.)

 Regards, niXman


Thanks.


K. Frank

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] FPU control word on startup

[K. Frank]

Hi Carl!

I very much think that 80 bits should be the default for
long doubles, even if Microsoft does differently.

On Mon, Nov 24, 2014 at 3:57 AM, Carl Kleffner cmkleff...@gmail.com wrote:
 I don't see the point, why computation accuracy has to be set to 0x37f per
 default. Usually computations are done with single or double precision
 today. Using 80bit long double precision is outdated

80-bit long doubles are hardly outdated.  Many people use
them and rely on them.

 and non portable.

That's quite a specious argument, given x86 (and other)
support for 80-bit precision dating back to the 8087.

Sure, hardware support for 80-bit doubles is not portable across
all platforms (nor is support for 64-bit doubles, nor for 32-bit
doubles, etc., etc.), but that's no reason to make mingw-w64
run suboptimally on very widespread hardware.  The article by
Kahan that Yaron linked to makes a very good argument (in the
context of java) that exact compatibility / portability is a bad idea
(and an illusory goal in any event).  (He also has a few choice words
about Microsoft's bad choice on this issue, as well he should.)

 It is
 just fine to have the possibilty to use 80bit longs doubles if needed (not
 possible with MSVC). Nevertheless I suggest double computation precision
 should be the default and extended double computation precision an option.
 Silently change the FPU settings can cause bad side effects (see the link on
 my first posting).

Although polemical in tone, Kahan's explains things very well.
Not using extended precision is sufficiently worse than using
it that not doing so can be considered wrong.

So, if Microsoft had a sqrt function that gave sqrt(16) == 5,
would you ask that mingw-w64 do the same in the name of
compatibility with Microsoft?

On common modern hardware, float is 32 bits, double is 64 bits,
and common modern hardware supports 80-bit doubles.  long double
is a different type from double.  Why force long double and double
to be the same 64 bits, when 80 bits is supported by hardware?

You want 64 bits, use double.  I want 80 bits, I'll use long double.
Why make it hard (or impossible) for me to use 80-bit long doubles
just because you want 64-bit doubles even if you accidentally type
long double?

Read Kahan.  He is absolutely an expert in this kind of thing (and
has been making these kind of arguments since before I was born,
which is saying something).

Mingw-w64 has the choice of doing what Microsoft does, or following
Kahan's recommendation.  Given that choice, it's Kahan, hands down.

Trust me -- if you become an expert on numerical analysis and
floating-point computation, you will agree with Kahan.  But you
don't need to become an expert -- just follow the experts' advice.

(And if the experts' advice differs from what Microsoft and python
and java, etc., etc. do, follow the experts' advice anyways.)


 2014-11-23 17:39 GMT+01:00 Yaron Keren yaron.ke...@gmail.com:

 It is a real incompatibility between VC and mingw. Visual C++ dropped
 support for 80 bit long doubles on x87 many years ago, in VC long doubles
 are 64 bit, which is why they use 0x27F. mingw still supports 80 long
 doubles on x87. As long this is the case, it is incosistent for mingw to set
 computation accuracy to 0x27f.

 The 'long double' size incompatibility requires mingw to implement various
 long-double functions including printf and scanf, independently of MSVCRT.

 So the decision is whether long doubles should be 64 or 80 bits. The
 control word is simply the result of this decision.

 BTW. see Kahan about long doubles (in Java, though),
 http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

Thank you Yaron -- this is an excellent reference.  It's well worth
reading (as is most anything by Kahan).


Happy Floating-Point Hacking!


K. Frank

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] FPU control word on startup

[K. Frank]

Hello Carl!

On Mon, Nov 24, 2014 at 9:55 AM, Carl Kleffner cmkleff...@gmail.com wrote:
 Hi K.Frank

 It's absolutely your (community) choice of course and fairly unproblematic
 if you stay inside the mingw-w64 system.

 It is however incompatible for MSVC compatibility even in case you never
 touch long doubles, as it affects double precision computation.

Yes,to clarify my earlier comments:  It is correct that even if you
use regular 64-bit doubles, the (x87-style) floating-point hardware
will (in extended-precision mode) compute intermediate results with
80-bit precision as long as the computations stay in the floating-point
registers, and only round them down to 64-bit doubles when they are
written to memory.

And yes, this can give different (almost always better) results than
computing intermediate results with 64-bit precision.  So, yes, this
will be incompatible with (but generally better than) the Microsoft
approach, even when only using doubles (i.e., not long doubles).

 See
 random-and-unexpected-exception-flt-divide-by-zero-and-exception-flt-invalid-operation.aspx
 or https://github.com/numpy/numpy/issues/5194 . At least it is a matter of
 documentation.

 I would like to ask you for an item in the mingw-w64 FAQ to explain the
 difference between the settings and how to choose double precision instead
 (linking CRT_fp8.o AFAIK)

Yes, very reasonable.  Whatever default behavior Kai  Co. choose for
mingw-w64, it should of course be documented, and, if different than the
Microsoft approach, that difference should be highlighted.  And, of course,
the end-user should be able to override the default behavior, whether it's
me who wants 80-precision for intermediate results, or someone like
yourself who has a use-case where 64-bit intermediate results are desired.
(Don't get me wrong -- I do believe that there are legitimate use-cases for
using 64-bit precision for intermediate results.  I just think they're rare.)

(I, of course, would vote for the default to be 80-bit long doubles with
80-bit precision for intermediate results based on my own experience,
but, much more importantly, based on the recommendation of the experts
such as Kahan.  But I would also vote for giving the end-user properly
documented mechanisms to override the default.)

 Cheers,

 Carl


Best.


Happy Extended-Precision Floating-Point Hacking!


K. Frank


 ...
 2014-11-24 15:01 GMT+01:00 K. Frank kfrank2...@gmail.com:

 Hi Carl!

 I very much think that 80 bits should be the default for
 long doubles, even if Microsoft does differently.
 ...

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Wt-interest] Building Wt with mingw-w64 -- prefer Mingw-builds or Win-builds?

[K. Frank]

Hi Adrian!

(Note, I haven't copied this response to the Wt list as it  doesn't
really concern Wt.)

I would like to follow up on gcc 4.9.0 vs. 4.9.2.

On Sun, Nov 23, 2014 at 6:22 AM, Adrien Nader adr...@notk.org wrote:
 Hi,

 On Sat, Nov 22, 2014, K. Frank wrote:
 Hello Lists!

 Should I use Mingw-builds or Win-builds to build Wt?

 First of all, both should work.

 I am the lead dev of win-builds so obviously I'm not an expert in
 mingw-builds.
 ...

 Will I be more likely to be successful using the Mingw-builds or the
 Win-builds version of the toolchain?  All else being equal, I would
 probably go with Mingw-builds because it appears to offer gcc 4.9.0.

 As I said at the beginning of this message, both should work.

 About the GCC version though: 4.9.0 was quite heavily bugged and while
 4.9.1 was much better it still had its issues. I don't know about GCC
 4.9.2; I haven't read many complaints about it but it came after the WB
 version freeze so it hasn't been studied for inclusion.
 In any case, you should probably avoid 4.9.0 and 4.9.1.

Would anyone have rough estimates for either Win-builds or Mingw-builds
(or other native x64 builds) for when gcc 4.9.2 is likely to be ready?  I'll
take Adrian's warning about 4.9.0 seriously, but I would like to upgrade
to 4.9 if a decent version becomes available in the near future.

 ...
 Boost isn't currently packaged since there had been no demand so far.
 The relevant entry in the bug tracker was opened a couple weeks ago and
 is at http://win-builds.org/bugs/index.php?do=detailstask_id=86 . It is
 scheduled for 1.6 and should therefore be packaged in roughly 4 to 6
 weeks (or earlier if someone else does it of course :) ).

As an aside, independent of Wt, I would probably give boost a try if a
pre-built package were available.

 Regards,
 Adrien Nader


Thanks very much for Win-builds (and Mingw-builds and everybody
else's builds I've used over the years).


K. Frank

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Wt-interest] Building Wt with mingw-w64 -- prefer Mingw-builds or Win-builds?

[K. Frank]

Hi Ruben!

On Sun, Nov 23, 2014 at 3:07 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 2014-11-23 17:19 GMT+01:00 K. Frank kfrank2...@gmail.com:
 ...
  ...
  Will I be more likely to be successful using the Mingw-builds or the
  Win-builds version of the toolchain?  All else being equal, I would
  probably go with Mingw-builds because it appears to offer gcc 4.9.0.
 
  As I said at the beginning of this message, both should work.
  ...
  About the GCC version though: 4.9.0 was quite heavily bugged and while
  4.9.1 was much better it still had its issues. I don't know about GCC
  4.9.2; I haven't read many complaints about it but it came after the WB
  version freeze so it hasn't been studied for inclusion.
  In any case, you should probably avoid 4.9.0 and 4.9.1.

 Would anyone have rough estimates for either Win-builds or Mingw-builds
 (or other native x64 builds) for when gcc 4.9.2 is likely to be ready?
 I'll
 take Adrian's warning about 4.9.0 seriously, but I would like to upgrade
 to 4.9 if a decent version becomes available in the near future.

 FYI, MSYS2 has GCC 4.9.2 in their repositories.

Yes, thanks.  I should have followed up on my earlier post.  I found
4.9.2 under mingw-builds:

   
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.2/threads-posix/seh/

(Note, mingw-builds says to use its installer, mingw-w64-install.exe,
but it seems to be broken, popping up a message box that says
ERROR res.  So I just downloaded and unzipped the .7z archive,
x86_64-4.9.2-release-posix-seh-rt_v3-rev0.7z, and that worked.)

 I'd also just try a new GCC version, and if it works for you just use it, at
 least for development.

Yes, that's what I'm doing (with 4.9.2).  Although, supposedly, 4.9.0
was very buggy.  We'll see ...

 ...
 As an aside, independent of Wt, I would probably give boost a try if a
 pre-built package were available.

 Boost isn't hard to build. But MSYS2 also has this in the repos. Along with
 a huge list of other packages.

I will say, boost is becoming increasingly annoying -- just about jumped
the shark, really.  It was already highly bloated:  Want a smart pointer?
Well then, download a template-metaprogramming parser generator!

But now, as far as I can tell, in order to build boost, you have to use
their own special build system, boost-build.  (Hey, could be great,
but yet one more non-standard dependency ...)  But, of course, you
have to BUILD boost-build, following an imperfectly documented
procedure.  With a little guesswork and monkeying around, I got their
bootstrap procedure to work (At least I think I did.), but the fact of
the matter is that when you set up such a long dependency chain,
things become fragile (as illustrated by the broken mingw-builds
installer).

 ...
 Cheers,

 Ruben


Best regards.


K. Frank

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Wt-interest] Building Wt with mingw-w64 -- prefer Mingw-builds or Win-builds?

[K. Frank]

Hello niXman!

(And thanks for the mingw-builds!)

On Sun, Nov 23, 2014 at 6:41 PM, niXman i.nix...@autistici.org wrote:
 K. Frank 2014-11-24 02:38:
 (Note, mingw-builds says to use its installer, mingw-w64-install.exe,
 but it seems to be broken, popping up a message box that says
 ERROR res.  So I just downloaded and unzipped the .7z archive,
 x86_64-4.9.2-release-posix-seh-rt_v3-rev0.7z, and that worked.)

 please show the MD5 of the mingw-w64-install.exe

I downloaded it today from:

   http://sourceforge.net/projects/mingw-w64/files/latest/download

I would be happy to give you the md5 if you could tell me an easy
way to calculate it.  I am running on 64-bit windows 7.

 Regards, niXman


Thanks.


K. Frank

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Wt-interest] Building Wt with mingw-w64 -- prefer Mingw-builds or Win-builds?

[K. Frank]

Hello niXman!

On Sun, Nov 23, 2014 at 7:26 PM, niXman i.nix...@autistici.org wrote:
 K. Frank 2014-11-24 02:53:

 I would be happy to give you the md5 if you could tell me an easy
 way to calculate it.  I am running on 64-bit windows 7.

 using MSYS/2:
 md5sum mingw-w64-install.exe

For mingw-w64-install.exe I get the following md5:

   C33AEC60739C44F208F171A74235B742

from http://onlinemd5.com/

(I don't have MSYS/2 installed.  I have no idea whether onlinemd5.com is
correct or not, but it might be.)

 Regards, niXman


Thanks.


K. Frank

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Wt-interest] Building Wt with mingw-w64 -- prefer Mingw-builds or Win-builds?

[K. Frank]

Hi niXman!

On Sun, Nov 23, 2014 at 8:11 PM, niXman i.nix...@autistici.org wrote:
 K. Frank 2014-11-24 04:06:
C33AEC60739C44F208F171A74235B742

 correct.
 you use proxy?

No, no proxy.  I use a wireless router that provides local, internal
ip addresses through dhcp, but is seen by the outside world as
a single ip address (dynamically) assigned by my isp.

 Regards, niXman


Thanks.


K. Frank

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [Wt-interest] Building Wt with mingw-w64 -- prefer Mingw-builds or Win-builds?

[K. Frank]

Hello Lists!

Should I use Mingw-builds or Win-builds to build Wt?

I am going to attempt to build Wt natively on 64-bit windows using
mingw-w64.  I am encouraged by Wim's comment in an earlier thread
that it ought to be possible:

   http://permalink.gmane.org/gmane.comp.web.witty.general/9973

Before doing so I intend to upgrade to a recent mingw-w64.

Will I be more likely to be successful using the Mingw-builds or the
Win-builds version of the toolchain?  All else being equal, I would
probably go with Mingw-builds because it appears to offer gcc 4.9.0.
Win-builds does offer a number of pre-built packages, but according
to the Wt wiki:

   http://redmine.webtoolkit.eu/projects/wt/wiki/Installing_Wt_on_MinGW

Wt's only dependency is boost, so the Win-builds packages don't look
relevant to my Wt project.

Any suggestions or advice would be very welcome.


Thanks.


K. Frank

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Wt-interest] Status of Wt with mingw-w64?

[K. Frank]

Hi Pau!

On Sat, Nov 8, 2014 at 6:55 PM, Pau Garcia i Quiles
pgqui...@elpauer.org wrote:
 Hello,

 It should work.

Do you think that it should work out-of-the-box, so to speak. or
would I expect to have to make some doable, but significant
modification to the source code?

 If you want to build Wt with all its dependencies, the easiest way is
 probably to add support for MinGW to winstng:

 https://elpauer.assembla.com/spaces/winstng/stream

 For the parts that may need some work, search for MSVC in
 cmake/CMakeLists.txt

If, figuratively speaking, I just change all occurrences of nmake
to mingw32-make, should things build correctly, or would I have
to port the code from msvc to mingw-w32?

If anyone (on either list) has tried building Wt with mingw-w64,
please summarize your experience -- either positive or negative.


Thanks.


K. Frank


 On Sun, Nov 9, 2014 at 12:00 AM, K. Frank kfrank2...@gmail.com wrote:

 Hello Lists!

 How practical is it to use Wt with mingw-w64?  Are there pre-built Wt
 binaries for a recent mingw-w64 toolchain?  Would I expect the build
 process to be reasonably smooth if I try to build Wt myself?
 ...
 Thanks.

 K. Frank

 --
 Pau Garcia i Quiles
 http://www.elpauer.org
 ...

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [Wt-interest] Status of Wt with mingw-w64?

[K. Frank]

Hello Lists!

How practical is it to use Wt with mingw-w64?  Are there pre-built Wt
binaries for a recent mingw-w64 toolchain?  Would I expect the build
process to be reasonably smooth if I try to build Wt myself?

I see reference to mingw-w64 on the Wt wiki:

   http://redmine.webtoolkit.eu/projects/wt/wiki/Installing_Wt_on_MinGW

It talks primarily about the TDM toolchain.  Also, it references gcc 4.7.1
and boost 1.5.2, so I'm guessing that the wiki entry is a couple of years
old.  All it says about mingw-w64 (or more specifically, mingwbuild) is
that you have to [work] around some compilation/linking issues.

There are some comments about  mingw-w64 in the mail archive for this
list, but they are mostly about (unsolved) problems.

Is Wt likely to work with mingw-w64, or would I be asking for trouble to
try it?


Thanks.


K. Frank

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] How to detect which threading model is used with the preprocessor?

[K. Frank]

Hi Etienne!

On Mon, Jun 30, 2014 at 4:09 AM, Etienne Sandré-Chardonnal
etienne.san...@m4x.org wrote:
 On Fri, 27 Jun 2014 14:00:06, K. Frank wrote:
 ...
 It's not entirely clear to me what your problem is.  (In your original
 question
 you asked whether you could detect pthreads vs. win32 threads with the
 preprocessor at compile time.)

 Why not use g++ / pthreads on linux, and mingw-w64's g++ / winpthreads
 on windows and just use pthreads for your threading code?  I would expect
 (expect, but don't know for certain) that the Qt's QThreads end up getting
 mapped to native pthreads on linux and to win32 threads on windows.  But
 unless you try to synchronize your own user pthreads with QThreads, I
 think you should be able to use both pthreads and QThreads in the same
 application both on linux and windows.

 Could you sketch out the precise use case that you're concerned about?

 I will probably do that (or even use std::thread).
 The concern I had were about these posts  articles stating that mingw-w64
 posix threads have a significant lower performance than win32 threads. As
 I'm writing a monte-carlo integration, which is running on clusters, and for
 which 5% perf drop is a money loss, I was thinking of writing a win32-thread
 specific code and use the win32 only mingw-w64 build for that. Hence the
 preprocessor question.

I would recommend that you use std::thread (assuming that you can
use c++11).  I have used std::thread in a Qt application without any
problem.  (I should note that it was a small, experimental application,
so it was never really stress-tested, and it did not use QThreads.)

In terms of performance, I would make the following comments:

I would imagine that your Monte Carlo integration parallelizes quite nicely.
Once you get your calculation threads spawned and running, there should
not be any performance difference between pthreads and win32 threads (or
std::threads and QThreads for that matter).  You would only expect to see
possible performance differences when spawning the threads or synchronizing
them (e.g., waiting on a mutex or condition variable).  Given that I believe
that all the different brands of threads end up being implemented in terms
of the native OS threads (pthreads on linux and win32 threads on windows),
I would not even expect to see any performance difference when context
switching the threads.

In your use case I imagine that you spawn a handful of calculation threads
(one for each core in the cluster?), let them calculate for a long time, and
then synchronize the threads so that you can collect the partial results
together.  So in my imagination, the calculation dominates, and the cost
of spawning and synchronizing the threads doesn't really matter.  So the
relative performance of spawning and synchronizing the threads also
doesn't matter.

Second, I played around with implementing std::thread for mingw-w64 in
terms of both win32 threads and pthreads (as implemented in mingw-w64's
winpthreads library).  For some things the win32 threads were faster (I think
spawning), and for some things the pthreads were faster (I think, if I remember
correctly, mutex contention).

So even if the performance of spawning / synchronization does matter to
you, I don't think that it goes without saying that win32 threads would be
faster for your use case.  If you really care, you would want to benchmark.

(One last comment:  If you do use win32 threads, you should not use
win32 mutexes.  These are heavy, expensive, interprocess synchronization
structures.  You should use instead win32 critical sections which are much
lighter weight -- intraprocess only -- unless, of course, you need to
synchronize
processes, not just multiple threads within a single process.)


 Etienne


Good luck.


K. Frank

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] How to detect which threading model is used with the preprocessor?

[K. Frank]

Hello Etienne!

On Fri, Jun 27, 2014 at 12:26 PM, Etienne Sandré-Chardonnal
etienne.san...@m4x.org wrote:
 On Thu, 26 Jun 2014 22:32:14, Ruben Van Boxem wrote:
 ...
 You can use win32 threads!! Just the C++11 thread, mutex and future
 stuff is build on top of the winpthreads library. Nothing is preventing
 you from using only Win32 Threads.

 So you confirm that the stackoverflow post
 (http://stackoverflow.com/questions/17242516/mingw-w64-threads-posix-vs-win32)
 is wrong about the sentence:

 So if you're using the the version of the runtime that was built with posix
 threads but decide to create threads in your own code with the win32 apis,
 you're likely to have problems at some point.
 ?

I can't give you a decisive confirmation, but I think that this is unlikely to
be true.  (Ruben and Kai should be able to offer greater certainty.)  It is
an implementation detail, so the (posix threads) implementation could be
doing something that would break win32 threads, but I would doubt it.

I would expect that you should be able to spawn and use pthreads, spawn
and use win32 threads (and spawn and use std::thread threads), and
everything should work fine.  The only place where I might expect trouble
would be if you tried to synchronize different brands of threads with one
another.

(Actually, I believe that all brands of threads are ultimately implemented as
win32 threads, so I bet you could synchronize all brands of threads on win32
synchronization structures.)

Also, the stackoverflow comment refers to the mingw wiki, even thought the
stackoverflow question asks about mingw-w64.  (mingw and mingw-w64 are
different projects.)  I doubt that the stackoverflow comment is true for either
mingw or mingw-w64, but it could, in principle, be true for mingw, but not for
mingw-w64.

 ...
 Well, it's not as easy... The code currently use a portable lib (Qt) for the
 threads but the question is about splitting a part of the app code for
 making a lib, intended to be used in a plugin sdk. And asking the customer
 to depend on external libraries is a sensitive topic...

It's not entirely clear to me what your problem is.  (In your original question
you asked whether you could detect pthreads vs. win32 threads with the
preprocessor at compile time.)

Why not use g++ / pthreads on linux, and mingw-w64's g++ / winpthreads
on windows and just use pthreads for your threading code?  I would expect
(expect, but don't know for certain) that the Qt's QThreads end up getting
mapped to native pthreads on linux and to win32 threads on windows.  But
unless you try to synchronize your own user pthreads with QThreads, I
think you should be able to use both pthreads and QThreads in the same
application both on linux and windows.

Could you sketch out the precise use case that you're concerned about?

 Thanks,

 Etienne


Happy Mixed-Thread Multithreaded Hacking!


K. Frank

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] How to detect which threading model is used with the preprocessor?

[K. Frank]

Hi Thomas!

On Thu, Jun 26, 2014 at 11:55 AM, C. Thomas Stover c...@thomasstover.com 
wrote:
 On Thu, 26 Jun 2014 09:12:30 +0200, Etienne Sandré-Chardonnal wrote:
 ...
 Will _GLIBCXX_HAS_GTHREADS work in these cases or is this mingw-only?
 ...

 The macro you reference made me curious. Gthreads (part of glib) written
 in C, is a wrapper around pthreads or win32 depending on how it was
 built. This allows for a mix of generic code that uses the wrappers and
 back-end specific code wrapped in #ifdef for portability.

 While I am aware that C++ 11 introduced a threading abstraction in-
 language, I am not aware of the details. Does it not internally wrap OS
 thread APIs?

Whether c++11's std::thread wraps the OS threading api internally
is an implementation detail.  (One would expect that it wraps at
least some of the lowest-level native threading and synchronization
primitives.)

g++'s std::thread, both on linux and windows (i.e., mingw-w64) is
implemented in terms of gthreads, which is a light-weight pthreads
wrapper (that is very pthreads-centric).  On linux, it uses native pthreads;
in the case of mingw-w64, it uses winpthreads, the mingw-w64 port
of pthreads to windows.

Kai can tell you more, but I believe that winpthreads uses native
windows threads for its underlying threads, but implements its
synchronization structures (mutexes, condition variables, c.)
in terms of low-level windows atomics, rather than in terms of
the analogous windows synchronization structures.

 Are you trying to also mix generic C++11 threading with os
 specific threading sections, or just use the native os APIs?

 Pthreads on windows is yet another variation on a theme since it would
 have to wrap the win32 threading api.

Again, mingw-w64 implements std::thread in terms of (the mingw-w64
port of) pthreads.  This wraps (as I believe) native windows threads, but
reimplements most thread synchronization in terms of lower-level windows
atomics.  That is, it partially wraps the windows threading api, and partially
reimplements equivalent functionality.

 Even with that I believe there is
 still a way to mix in some straight up win32 api code if so needed. I
 would be interested in hearing the details form those who know.

In general I wouldn't try this (except for fun), as you would be depending
on implementation details, but I do believe that you could spawn a
(mingw-w64) std::thread or pthread, and then synchronize it on, for
example, a windows critical section (a type of windows mutex).  This
should work because (as I believe), the underlying thread is, in fact,
a windows thread.

But you would not, for example, be able to use a windows condition
variable with a (mingw-w64) std::mutex or pthreads mutex, because
(as I believe) winpthreads does not use the windows synchronization
structures under the hood.


Happy Hacking!


K. Frank

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] printf(%*.*f,d) broken?

[K. Frank]

Hi Jim!

On Fri, May 9, 2014 at 5:29 PM, Jim Michaels j...@yoohoo.com wrote:
 I could not find a good example on this because examples in books are scarce
 as hen's teeth. search engines ignore the * character and maybe even
 interpret it like a wildcard. :-/ so examples on the web are out.

 #include stdio.h
 int main(void) {
 double d=1234567890.123456789;
 int width=7,precision=3;//tried 3 and 9
 printf(width=%d, precision=%d, d=%*.*f\n, width, precision, d);
 //generates forever loop of spaces, program hangs.
 return 0;
 }

I think that you have too few arguments to your printf call.

I don't actually know what %*.*f does, but I assume it uses printf
arguments to specify the actual format.  But (according to my
assumption) width=%d, precision=%d has already used up the
arguments that %*.*f is expecting.

When I change the line

   printf(width=%d, precision=%d, d=%*.*f\n, width, precision, d);

to

   printf(width=%d, precision=%d, d=%*.*f\n, width, precision,
width, precision, d);

the program works as I would expect, printing out

   width=7, precision=3, d=1234567890.123

 I need to use this. but it seems broken. it just locks up generating spaces
 no matter what I put in for numbers. I don't think that's right.

 Jim Michaels
 ...


Good luck.


K. Frank

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Trouble with pow()

[K. Frank]

Hello Roland!

On Mon, Mar 24, 2014 at 11:19 AM, Roland Schwingel rol...@onevision.com wrote:
 Hi Kai...

 Kai Tietz ktiet...@googlemail.com wrote on 24.03.2014 15:19:03:

   Hi Roland,
  
   could you please provide a small testcase
   demonstrating this end-less loop?
 Testcase is quite simple:

 #include stdio.h
 #include math.h

 int main(int argc,const char **argv)
 {
 printf(before\n);
 pow(2,-2147483648.);
 printf(after\n);

 return 0;
 }

   I assume that this issue got already fixed in the past.  And there is
   for sure no endless loop on the iteration due in my repository we
   iterate here on an unsigned variant of y, so there is no such thing.
   Might it be that you were using a different version then I do?
 Here we are running the most recent released mingw-w64-crt (3.1).
 I even looked into trunk. The code there was not changed for months.

Just to confirm that you are not going totally crazy, I do see the
endless loop with an older version of mingw-w64.

pow_test.c is your test-case code from above.

   C:\gcc --version
   gcc (rubenvb-4.8-stdthread) 4.8.1 20130324 (prerelease)

   C:\gcc -o pow_test pow_test.c

   C:\pow_test
   before
   ^C

Here, the ^C indicates that I killed pow_test because it had hung.

Thanks for the heads-up.  I'll know to be on the lookout for this
bug, at least until my next upgrade.

 Greetings,

 Roland


Best.


K. Frank

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] libwinpthreads dependency should be optional

[K. Frank]

Hello All!

On Sun, Mar 23, 2014 at 6:13 PM, JonY j...@source.net wrote:
 On 3/24/2014 01:20, Adrien Nader wrote:
 On Sun, Mar 23, 2014, LRN wrote:
 * Win32 threading * POSIX threading

 It's a matter of adding native-W32-threads-using code to GCC. Doing
 that will remove winpthreads dependency. So far no one seems to be
 bothered enough to code this.

I did do this on an experimental basis a few years back. I didn't
do exhaustive testing, but according to my basic tests, all of
std::thread was working.  (That was my goal.)

The implementation used windows critical sections for mutexes,
and windows condition variables for condition variables.  The only
feature that didn't map neatly to the windows api in this scheme
was std::timed_mutex, but with some extra work I was able to
implement std::timed_mutex in terms of critical sections.

 The main difficulty is in handling all the OS versions and it's not
 always that easy.


 iirc there was some work done some time ago using win32 native
 threading,

Yes, as described above.

 but it will cut off XP users completely due to how
 conditional variables are only available in Vista and later.

Yes, windows condition variables are not supported in xp, so the
above scheme only works for vista and later.

My goal was to get gcc's std::thread working on windows, and the
windows-api-based implementation accomplished this.  But it's fair
to say that even though pthreads is not part of the c++ standard
(and I use std::thread in preference to pthreads for my own code),
pthreads is very widely used.  So although mingw-w64 doesn't need
pthreads for c++11 compliance, it's clearly very valuable to ship a
mingw-w64 that supports pthreads.  And once you've done that, why
not base std::thread on pthreads?  Is there really any value is shipping
two versions of std::thread?  From my perspective (that of using
portable, standard c++11 std::thread for threading), as long as
std::thread works, I really don't care whether std::thread is based
on pthreads or not.

But I would really NOT want a version of mingw-w64 that only supported
part of the c++11 standard, i.e., that didn't support std::thread.


Happy Multi-Threaded Hacking!


K. Frank

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building a library for use under Visual Studio 2008

[K. Frank]

Hi Suresh!

I am not fully certain of my answer, so I hope others will correct me if
I'm wrong.

On Tue, Feb 25, 2014 at 9:36 PM, Suresh Govindachar
sgovindac...@yahoo.com wrote:

 Hello,

 I use MingGW64 for my development work on Windows 7 64 bit.
 ...
 I use -std=c++0x and -static-libgcc -static-libstdc++ flags.

 Can my lib*.a files be used by others who work inside Visual Studio 2008
 (which does not support the latest C++ standard library)?  I can make
 sure that the header files needed by others do not use the newer C++
 features.

I am almost certain that you cannot use mingw-w64-built c++ libraries
with visual studio.  I believe that the c++ abi is different, and I am almost
certain that the c++ name mangling is different.

(I assume that you are using c++ because you mention -std=c++0x.  Note,
you might consider upgrading to -std=c++11x -- or to -std=gnu++11, if
you want the gnu extensions -- if you're using a relatively recent version.)

(As I understand it, mingw-w64 tries to ensure, but does not guarantee
that the abi remain stable from one tool-chain version to the next.  I seem
to recall people saying that the VS abi almost always changes from one
version to the next, but I'm not sure about this.)

I have heard talk that if you stick to c (not c++), you might be able to mix
mingw-w64 with VS, but that it's tricky and risky, and generally worth
staying away from.

 If my lib*.a files cannot be used in a Visual Studio 2008 project, what
 would I need to do to build a library that can be used by others who
 work inside Visual Studio 2008?

As I understand it, you would need to compile your c++ code and build
your libraries with the VS 2008 tool-chain.  Unfortunately, if your code is
using newer c++ features not supported by VS 2008, you may be stuck.

 While I am familiar with generating and using lib*.a files, I have no
 clue about dll files.

I believe that all of the above comments apply to dll's as well as static
libraries.

 Thanks,

Sorry for the negative news (and hopefully others will correct anything I
have wrong here).

 --Suresh


Good luck.


K. Frank

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Macro 'WIN32' not defined when specify -std=c++11

[K. Frank]

Hi Leopold!

On Wed, Jan 15, 2014 at 8:25 PM, Leopold Freeman  wrote:
 Hi there,

 I wrote a simple test program:

 /
 #include iostream
 using namespace std;
 int main()
 {
 #if defined(WIN32)
  cout  WIN32  endl;
 #else
  cout  no WIN32  endl;
 #endif
  return 0;
 }
 /

 If:
 $g++ -std=c++11 test.cpp -o t
 $./t
 no WIN32

 If:
 $g++ test.cpp -o t
 $./t
 WIN32

 ...

I see the same result as you.

But if I compile with -std=gnu++11, I get WIN32.

I believe that not specifying -std is equivalent to -std=gnu++03, which
means the 03 standard plus gnu extensions.

I get:

   (no -std) WIN32
   -std=c++03no WIN32
   -std=gnu++03 WIN32
   -std=c++11no WIN32
   -std=gnu++11 WIN32

So it looks to me as if having WIN32 defined is considered to be a
gnu extension.  (Why, I don't know.)  And that the WIN32 issue
does not seemed to be linked specifically with the c++11 standard.

 ...

 I use this build:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.8.2/threads-posix/sjlj/i686-4.8.2-release-posix-sjlj-rt_v3-rev2.7z/download

I used:

   C:\g++ --version
   g++ (rubenvb-4.8-stdthread) 4.8.1 20130324 (prerelease)

 Regards,

 Leopold


Happy Hacking!


K. Frank

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] mingw and mingw

[K. Frank]

Hello Wynfield!

On Wed, Dec 4, 2013 at 8:56 AM,  wynfi...@gmail.com wrote:

 mingw-w64-public@lists.sourceforge.net

 It's been a while and I'm a confused over which Mingw is which.

Mingw (www.mingw.org) and mingw-w64 (mingw-w64.sourceforge.net)
are two different projects with two different mailing lists
(mingw-us...@lists.sourceforge.net and mingw-w64-public@lists.sourceforge.net,
respectively).

 I preferring a manual install downloaded the files stated as needed for a 
 minimal system plus the gbd and document packages from:
URL = http://http://www.mingw.org//wiki/InstallationHOWTOforMinGW

I think the current set-ups are such that it is easier to carry out a
purely manual install process with mingw-w64.

 Then I recalled reading somewhere, back when, that there is also a different 
 Mingw.  Also I note that there is also a Mingw64 which I assume will only run 
 on 64 bit machines, but could be ran or a 32 bit to build 64 bit program?

If I remember correctly, mingw-w64 provides both 32-bit and 64-bit
toolchains, while I think that mingw only provides the 32-bit version.
(Hopefully some one will chime in if I have this wrong).  I do believe
that mingw is planning a future 64-bit version.

 If there are multiple flavors of Mingw and different x-bit packages I would 
 like to know which is which, what is different.

Again, two separate projects with two separate web sites and two
separate mailing lists.  (This is the mingw-w64 mailing list.)

Both compilers work -- I can't really say which would be better
suited to your purposes.

 Thank you.

Good luck., and ...


Happy Mingw/w64 Hacking!


K. Frank

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] C++11 threading with non-posix versions

[K. Frank]

Hello Victor (and Ruben)!

On Sat, Nov 16, 2013 at 10:39 AM, Ruben Van Boxem ru...@box.mail wrote:
 2013/11/16 Victor Bombi bo...@away.net

 the information provided here
 http://qt-project.org/wiki/MinGW-64-bit
 could be then confusing or inacurate?

 If Qt people say there might be a performance degradation (I read the web
 page to only talk about C++11 threading features), then I believe them. I
 guess I'm not very familiar with heavy threading applications.

 Ruben

 - Original Message -
 From: Ruben Van Boxem

 2013/11/16 Victor Bombi boxoff...@bomb.net

 Is there any plan to write this headers on top of win32 api?

 No, and any efficient implementation will remove Windows XP compatibility.
 Winpthreads is implemented on top of the Win32 API, and GCC's internal
 thread API is pretty much a pthreads abstraction, so it's really only just
 one extra layer. If you have actual performance issues, I'm sure Kai will be
 happy to try and resolve them for you by improving winpthreads.

 Ruben
 ...

I did some crude mingw-w64 std::thread performance tests a few years
back comparing the winpthreads std::thread implementation with a
win32-based implementation.

In general, sometimes winpthreads was faster, and sometimes slower.
If I remember correctly, I think winpthreads was significantly slower in
thread creation (and maybe faster in mutex access in the face of
contention), but I reasoned that thread creation is in general a little
bit expensive: if you don't create a lot of threads, the additional cost
won't really matter, and if you create enough threads for the additional
winpthreads cost to matter, the cost of creating native win32 threads
would also matter, and you should probably be using a thread pool.

Bear in mind, this was a while ago.  Winpthreads has presumably been
tuned up some since then, and the win32 implementation was competent,
but not highly optimized.


Happy Multi-Threaded Hacking!


K. Frank

--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] libwinpthreads mutexes

[K. Frank]

Hi Vadim!

On Thu, Sep 12, 2013 at 11:16 AM, Vadim  wrote:
 On Thu, Sep 12, 2013 at 9:32 AM, K. Frank  wrote:

 Hello Kai and Vadim!
 ...
  2013/9/12 Vadim :
  Hi,
  I am investigating performance problems in binary compiled with
  mingw-w64,
  and libwinpthreads mutex comes at the top of my profile.
  ...
 Just some background comments -- not directly relevant to
 mingw-w64:
 ...
 I experimented with using both windows mutexes and windows
 critical sections for implementing std::thread with mingw-w64;
 not surprisingly, the critical-section version was significantly
 faster, at least when it came to creating a lot of std::mutex
 objects.

 Precisely.  In the absence of contention, critical sections can be up to
 sever hundred times faster than kernel mutexes.
 ...
 Two down-sides I found with windows critical sections:  They are
 relatively recent -- I think Vista and later.  (I didn't really care
 about this.)

 They've been around since win95.   In Vista they were modified such that
 InitializeCriticalSection will not fail under low-memory conditions.

Thanks, I didn't know that.

  ...
 Happy Pthreads Hacking!

 Before we embark on that, I'd like to clarify a couple more things:

 1. Have you guys considered adopting/forking phtreads-win32?  I believe this
 is what the regular mingw uses.  That library looks more mature, at least as
 far as mutexes go.

Let me speak beyond my competence here ...  (Kai, please correct
me if I have anything wrong.)

There are possibly two issues:

I think that pthreads-win32 has a less flexible license.  I think one
reason for winpthreads is to offer users a more flexible license.
(Maybe they don't have to ship source code for pthreads-win32,
or something.)

I do know that there is an issue with thread handles.  pthreads handles
are officially opaque, however the historical unix / linux pthreads
implementations all (nearly all?) used integral handles.  pthreads-win32,
on the other hand, uses a structure for the handle (which I think it is, in
principle, allowed to do).

However, as I understand it from Kai, lots and lots of software that
uses pthreads makes use of the fact that pthreads handles are
integral values.  (I know, for example, that gcc's pthreads version
of std::thread makes this assumption.)  So pthreads-win32 breaks
this code.  (Technically this code is non-compliant, but still, it's
better not to break it if you don't have to.)

So I believe that one of Kai's key motivations for winpthreads was
to have it use integral thread handles to be consistent with unix /
linux implementations.

There may be other issues, but licensing and integral handles are
the two that I'm aware of.

 ...
 Vadim


Best.


K. Frank

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] it does not have memory

[K. Frank]

Hello Incongruous!

On Sun, Sep 8, 2013 at 6:52 PM, Incongruous inc...@lookout.com wrote:
 I was looking at
 C:\MinGW64\x86_64-w64-mingw32\include
 and it does not have memory,

In my installation, memory is in:

   [some sort of mingw-w64 root]\mingw64\include\c++\4.8.1

 why?

I don't really know why, but it looks like memory and other c++-specific
things are being put in their own c++ subdirectory of include.

Again, I don't know the details, but g++ knows somehow to look there
automatically.


Good luck.


K. Frank

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] The API supported by g++11_64bit

[K. Frank]

Hi Incongruous!

On Fri, Sep 6, 2013 at 7:56 PM, Incongruous congru...@lookout.com wrote:
 OKay?

 Code Snip
 
 #include memory //share_ptr
  std::shared_ptrabc::someClass apx; //--Does not work

 Error
 
 g++-c -g -I/c/abc -I/c/abc/gui/msg/ -MMD -MP -MF

std::shared_ptr is new to c++11, so you probably have to turn on
c++11 with g++.  (Actually only sort of new; as you know, shared_ptr
had been in namespace tr1.)

= test.cpp =

#include memory
std::shared_ptrint p;

= test.cpp =

The compile command g++ -std=c++11 -c test.cpp works, but
g++ -c test.cpp fails with the error:

   test.cpp:2:1: error: 'shared_ptr' in namespace 'std' does not name a type
std::shared_ptrint p;
^

My version of g++ is

   g++ --version
   g++ (rubenvb-4.8-stdthread) 4.8.1 20130324 (prerelease)

 What do I want?
 ~~~
 I would like to know if MinGW is able to compile the line above or if C++11
 compliant. I know that VS2010+ has not problem compiling the code above.

Yes, mingw-w64 is able to compile this code, but you have to
tell it explicitly to use c++11; is doesn't by default.

(You can also use -std=gnu++11 if you want both c++11 and
some of the gniu extensions.)

 TIA (Thanks in advance )


Happy C++11 Hacking!


K. Frank

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 1/2] synchapi.h: APIs are not forbidden on Windows Store

[K. Frank]

Hello All!

On Mon, Aug 19, 2013 at 6:58 AM, Rafaël Carré fun...@videolan.org wrote:
 Le 19/08/2013 11:58, Jacek Caban a écrit :
 ...
 Which exact APIs were problematic? I checked a few for which you removed
 guards, and they should be forbidden, so you probably change too much.

 EnterCriticalSection is allowed, although I just checked CreateMutex and
 it is indeed forbidden.

I wonder what the reason for this distinction is.  The only thing I can think
of is that a windows mutex is a cross-process synchronization object (It
can, of course, be used intraprocess, too.), while a windows mutex is a
purely intraprocess synchronization object (used for synchronizing threads
in a single multi-threaded process).

Maybe windows-store apps aren't allowed to talk to one another (or
interfere with one another).  Maybe the problem is just that is a windows
mutex is a heavier-weight os object, and store apps aren't allowed to bog
the system down or use up heavier os resources.

Or perhaps store apps are being required to be able to run on some other
platform (rt?  phone?  not released yet?) that doesn't support windows
mutexes.

Or maybe the cross-process nature of the mutex (or a bug) produces
some kind of security issue.

I am just wondering what the philosophy behind the limitation is.

Any thoughts?


Thanks.


K. Frank

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Fwd: ERR_remove_thread_state not found in LIBEAY32.dll with mingw-w64

[K. Frank]

Hi List!

I'm taking the liberty of cross-posting this curl-lib question to
mingw64.  (I believe this post is awaiting moderation over on
curl-lib.)  I do see a fair amount of mingw-w64-specific libcurl
discussion on this list, so maybe somebody can help me out.

-- Forwarded message --
From: K. Frank 
Date: Fri, Aug 9, 2013 at 8:48 PM
Subject: ERR_remove_thread_state not found in LIBEAY32.dll with mingw-w64
To: curl-library


Hello List!

I am new to libcurl, and am trying to use it with mingw-w64.

I have written an compiled a very simple test program and when I run it
I get a windows pop-up message box that says:

   Entry Point Not Found

   The procedure entry point ERR_remove_thread_state could not
   be located in the dynamic library LIBEAY32.dll

Some details:

My program is technically c++, and contains a single call to
curl_global_init (CURL_GLOBAL_ALL);

It seems to compile and link correctly:

   g++ -g -o libcurl_test libcurl_test.cpp -lcurldll

I am pretty sure that I have the proper include and lib directories set up
for building my test app and have the proper bin directory in my path
when attempting to run it.

It is worth noting that the command line curl.exe (that came with the libcurl
download) does run without error, e.g.,

   curl --version

   curl 7.31.0 (x86_64-pc-win32) libcurl/7.31.0 OpenSSL/1.0.0k
zlib/1.2.8 WinIDN libssh2/1.4.3 librtmp/2.3
   Protocols: dict file ftp ftps gopher http https imap imaps ldap
pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
   Features: AsynchDNS GSS-Negotiate IDN Largefile NTLM SSL SSPI libz

The version I am using I downloaded from http://curl.haxx.se/download.html,
from the Win64 - MinGW64 section.  I downloaded the devel package:

   curl-7.31.0-devel-mingw64.7z

and unzipped it.

I have seen some comments that made it sound like  ERR_remove_thread_state
is new or deprecated or something, and that having a version mismatch between
libcurl and libssl could cause this problem.  But I believe I am using
libcurl and
libssl both from curl-7.31.0-devel-mingw64.7z, so I would imagine that they are
consistent.

Note, I did not build libcurl myself with mingw-w64, so there could be
a mismatch
between the libcurl compiler and the version I am using, but I don't
see how that
kind of thing could cause this specific problem.

I am using mingw-w64 g++ 4.8.1, downloaded as:

   x86_64-w64-mingw32-gcc-4.8-stdthread-win64_rubenvb.7z

and running 64-bit windows 7.


Thanks for any advice.


K. Frank

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Semi-OT -- libcurl and mingw-w6 / c++

[K. Frank]

Hello niXman!

On Wed, Aug 7, 2013 at 2:30 PM, niXman i.nix...@gmail.com wrote:
 2013/8/7 K. Frank

 Do I anticipate any issues using libcurl with mingw-w64?  If so, what
 should I look out for and how might I deal with it?

 No, libcurl is easy to build with mingw-w64.

Thanks for the confirmation.

 Second, right now I use curl to fetch data files, and then I read them
 into a program as an ifstream and use getline.  In an ideal world, I would
 want to be able to get an istream from a libcurl call.  As libcurl is
 c-based, I assume that I don't get this out of the box.  Would anyone
 have suggestions for hooking up a libcurl call to an istream?  Or
 would it not be worth the bother, and I should just use the buffer-based
 callback scheme that seems to be the libcurl way of doing it?

 Please read: http://curl.haxx.se/libcurl/c/post-callback.html

Looks straightforward.  (I was just wondering if there were any
shortcuts.)


 Regards,
 niXman

I appreciate your feedback.


K. Frank

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Semi-OT -- libcurl and mingw-w6 / c++

[K. Frank]

Hello List!

I'll pretend that this is on topic because I'm asking about using libcurl
with mingw-w64.

I downloaded curl and libcurl, I think from the curl web site.  I have
been using curl (from the windows command line) to fetch line-based
text data from a web site.

I am now considering building this into a program.

My questions:

Do I anticipate any issues using libcurl with mingw-w64?  If so, what
should I look out for and how might I deal with it?

Second, right now I use curl to fetch data files, and then I read them
into a program as an ifstream and use getline.  In an ideal world, I would
want to be able to get an istream from a libcurl call.  As libcurl is
c-based, I assume that I don't get this out of the box.  Would anyone
have suggestions for hooking up a libcurl call to an istream?  Or
would it not be worth the bother, and I should just use the buffer-based
callback scheme that seems to be the libcurl way of doing it?

This is on 64-bit windows 7, and the curl.exe that I downloaded
appears to be a 64-bit program.

Thanks for any suggestions.


K. Frank

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Any color on not-so-long long doubles (about 18 decimal digits)?

[K. Frank]

Hello List!

On 64-bit mingw-w64:

   g++ (rubenvb-4.8-stdthread) 4.8.1 20130324 (prerelease)

on 64-bit windows 7, I'm seeing that long doubles have a precision of about
18 decimal digits.  I would guess that this is a legacy of the old 8087 80-bit
internal floating-point number.

From a quick test program (no explicit compiler flags):

   numeric_limitsfloat::digits10 = 6
   numeric_limitsdouble::digits10 = 15
   numeric_limitslong double::digits10 = 18

   numeric_limitsfloat::max_digits10 = 9
   numeric_limitsdouble::max_digits10 = 17
   numeric_limitslong double::max_digits10 = 21

   sizeof(float) = 4
   sizeof(double) = 8
   sizeof(long double) = 16

As you can see, long double offers only a modest increase in precision over
double, but takes fully twice the space.

Also, Intel's old 80-bit floating-point format fits in five 16-bit
words (which fits in
three 32-bit words).  I am guessing that alignment issues on a 64-bit machine
make it not worth the bother to use less than a full two 64-bit words to hold a
long double, even though (if I'm right about the 80-bit
representation), there's a
fair amount of wasted space.

Does this all sound right?


Thanks for any thoughts.


K. Frank

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Any color on not-so-long long doubles (about 18 decimal digits)?

[K. Frank]

Hi Jon!

Thanks for your reply.

On Sat, Jul 20, 2013 at 12:17 PM, JonY jo...@users.sourceforge.net wrote:
 On 7/20/2013 23:43, K. Frank wrote:
 Hello List!

 On 64-bit mingw-w64:

g++ (rubenvb-4.8-stdthread) 4.8.1 20130324 (prerelease)

 on 64-bit windows 7, I'm seeing that long doubles have a precision of about
 18 decimal digits.  I would guess that this is a legacy of the old 8087 
 80-bit
 internal floating-point number.

From a quick test program (no explicit compiler flags):
 ...
numeric_limitslong double::digits10 = 18
 ...
numeric_limitslong double::max_digits10 = 21
 ...
sizeof(long double) = 16

 As you can see, long double offers only a modest increase in precision over
 double, but takes fully twice the space.

 Also, Intel's old 80-bit floating-point format fits in five 16-bit
 words (which fits in
 three 32-bit words).  I am guessing that alignment issues on a 64-bit machine
 make it not worth the bother to use less than a full two 64-bit words to 
 hold a
 long double, even though (if I'm right about the 80-bit
 representation), there's a
 fair amount of wasted space.

 Does this all sound right?

 on a 64-bit machine, floating point goes on SSE registers, which support
 2x64-bit floats (128-bit per xmm reg). On a 32-bit machine, it goes on
 the 80-bit x87 fpu.

That would certainly make sense, but it doesn't square with what
numeric_limits is telling me:

   numeric_limitslong double::digits10 = 18
   numeric_limitslong double::max_digits10 = 21

Just to check that numeric_limits isn't lying to me I ran a small program
that adds and subtracts 1.0 to and from a small long double.  This agrees
with numeric_limits and shows about 20 decimal digits of precision.

   ---
   d = 1e-017
   (d += 1.0;  d -= 1.0;)
   d = 9.97466e-018
   ---
   d = 1e-018
   (d += 1.0;  d -= 1.0;)
   d = 9.75782e-019
   ---
   d = 1e-019
   (d += 1.0;  d -= 1.0;)
   d = 1.0842e-019
   ---
   d = 1e-020
   (d += 1.0;  d -= 1.0;)
   d = 0
   ---

I compiled the test program without any special compiler flags.  Do I
need to somehow enable the SSE registers you mentioned in order
to take advantage of them?

 Use something like MPFR if you want arbitrary high precision math
 independent of hardware capabilities.

No, I don't need that.  I was just a little curious about what I saw, and
thought an 80-bit long double was a little skimpy for a modern, 64-bit
machine.


Thanks for any additional wisdom.


K. Frank

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Any color on not-so-long long doubles (about 18 decimal digits)?

[K. Frank]

Hello Jon and Kai!

On Sat, Jul 20, 2013 at 11:54 PM, JonY 10bottlesofb...@gmail.com wrote:
 On 7/21/2013 11:47, Kai Tietz wrote:
 Actually gcc provides libquadmath for 128-bit floating point math routines.

 It might be worth a look.

 Aloha
 Kai

 Looks like it does provide the math routines, I thought it was just
 providing support constructs. Anyway, be aware that license is LGPL 2.1
 or later.

Thanks for the clarifications.

(Again, I don't feel that I'm in need of greater precision.  I'm just trying
to make sure I understand what I'm looking at.)


Adios!


K. Frank

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Can't output (ostream ) std::chrono::duration

[K. Frank]

Hi Ruben!

On Mon, Jul 15, 2013 at 3:41 AM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 2013/7/5 K. Frank kfrank2...@gmail.com

 Hello List!

 The following code snippet fails to compile:

auto us = std::chrono::microseconds(7);
std::cout  us  std::endl;   // error

 (But std::cout  us.count()  std::endl; works as expected.)

 So it looks like std::chrono::duration isn't set up for .

 Stroustrup's c++11 faq:

http://www.stroustrup.com/C++11FAQ.html

 suggests that something like this should work:

nanoseconds d = monotonic_clock::now() - t;  // we want the result
 in nanoseconds
cout  something took   d  nanoseconds\n;

 Should I be able to insert a std::chrono::duration into an ostream?
 ...

 Both GCC 4.8 with libstdc++:
 http://coliru.stacked-crooked.com/view?id=71573ce00efe8788aa6fcd371fd4e2c0-92a6b8b905b3338bdfc1eb08c231d068
 and clang 3.3 with libc++:
 http://coliru.stacked-crooked.com/view?id=71573ce00efe8788aa6fcd371fd4e2c0-5850791944d571e696c4e044384770e7
 show what you are doing isn't right.

Yes, I've come to the same conclusion.

 I don't have the willpower to dig up a
 Standard quote,

I haven't been able to find any reference to inserting a duration
into an ostream in the standard, so I conclude that you can't.

(It's the problem of proving a negative.  I don't expect to find a
statement in the standard saying that you can't do it.  Also,
such a feature, e.g., operator(ostream, duration) could, in
principle, be defined anywhere in the standard, although I would
expect to find it in the duration section, and I've looked through
that section fairly carefully.)

I think that the c++11 faq example I cited is just a typo; a later
example inserts duration.count().

 but this page might give you some hints on how to output
 chrono durations:
 http://en.cppreference.com/w/cpp/chrono/duration

 Keep that website bookmarked, it's an awesome reference.

Yes, good reference.  Thanks.

 Ruben


Best.


K. Frank

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Can't output (ostream ) std::chrono::duration

[K. Frank]

Hello List!

The following code snippet fails to compile:

   auto us = std::chrono::microseconds(7);
   std::cout  us  std::endl;   // error

(But std::cout  us.count()  std::endl; works as expected.)

So it looks like std::chrono::duration isn't set up for .

Stroustrup's c++11 faq:

   http://www.stroustrup.com/C++11FAQ.html

suggests that something like this should work:

   nanoseconds d = monotonic_clock::now() - t;  // we want the result
in nanoseconds
   cout  something took   d  nanoseconds\n;

Should I be able to insert a std::chrono::duration into an ostream?

Here's a test program:

   #include chrono
   #include iostream
   int main (int argc, char *argv[]) {
 auto us = std::chrono::microseconds(7);
 // std::cout  us  std::endl;  //error
 std::cout  us.count()  std::endl;
   }

If I uncomment the line labelled error, I get the following
compile-time error:

g++ -std=gnu++11 -o duration_io_test duration_io_test.cpp
duration_io_test.cpp: In function 'int main(int, char**)':
duration_io_test.cpp:5:16: error: cannot bind 'std::ostream {aka
std::basic_ostreamchar}' lvalue to 'std::basic_ostreamchar'
   std::cout  us  std::endl;  //error
^
In file included from .\mingw64\include\c++\4.8.1\iostream:39:0,
 from duration_io_test.cpp:2:
.\mingw64\include\c++\4.8.1\ostream:602:5: error:   initializing
argument 1 of 'std::basic_ostream_CharT, _Traits
std::operator(std::basic_ostream_CharT, _Traits, const _Tp)
[with _CharT = char; _Traits = std::char_traitschar; _Tp =
std::chrono::durationlong long int, std::ratio1ll, 100ll ]'
 operator(basic_ostream_CharT, _Traits __os, const _Tp __x)
 ^

I am using the following version of g++:

   C:g++ --version
   g++ (rubenvb-4.8-stdthread) 4.8.1 20130324 (prerelease)

There is nothing urgent about this for me -- using duration.count() works just
fine for my purposes.  I'm just wondering how things are supposed to work.


Thanks.


K. Frank

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] strftime doesn't parse %T

[K. Frank]

Hello List!

strftime does not seem to parse the %T format specifier.

First of all, I don't actually know what is supposed to happen.  However,
this reference:

   http://www.cplusplus.com/reference/ctime/strftime/

states that %T is supposed to be a synonym for %H:%M:%S:

   %T   ISO 8601 time format (HH:MM:SS), equivalent to %H:%M:%S   14:55:02

Anyway, when I use %T in my format string, strftime returns 0 as the
number of characters copied to the output buffer.

This is nothing urgent for me -- I can simply use %H:%M:%S.  I only
bring this up because g++ seems not to agree with some random bit of
documentation I found on the internet.

Here's the output from a sample program:

   C:\strftime_test.exe
   cnt1 = 17, buf1 = 20130702-13:14:15
   cnt2 = 0, buf2 =

the compile line:

   C:\g++ -o strftime_test strftime_test.cpp

the compiler version:

   C:\g++ --version
   g++ (rubenvb-4.8-stdthread) 4.8.1 20130324 (prerelease)

and the test program:

=== strftime_test.cpp ===

   #include ctime
   #include iostream
   int main (int argc, char *argv[]) {
 tm mytm = { 15, 14, 13, 2, 6, 113 };  // not portable

 char buf1[129];
 int cnt1 = strftime (buf1, 128, %Y%m%d-%H:%M:%S, mytm);
 std::cout  cnt1 =   cnt1  , buf1 =   buf1  std::endl;

 char buf2[129];
 int cnt2 = strftime (buf2, 128, %Y%m%d-%T, mytm);
 std::cout  cnt2 =   cnt2  , buf2 =   buf2  std::endl;
   }

===  ===


Thanks for any feedback.


K. Frank

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] strftime doesn't parse %T

[K. Frank]

Hi Ozkan!

Thank you for your explanation.

On Wed, Jul 3, 2013 at 2:26 PM, Ozkan Sezer  wrote:
 On Wed, Jul 3, 2013 at 9:08 PM, K. Frank  wrote:
 Hello List!

 strftime does not seem to parse the %T format specifier.
 ...
 Thanks for any feedback.

 K. Frank

 strftime() is imported from msvcrt.dll, therefore it behaves the way MS
 authored it.

Thanks.  That makes good sense.

Just as a follow-up, when I look at msdn's documentation for strftime,
e.g.:

   http://msdn.microsoft.com/en-us/library/fe06s4ak(v=vs.80).aspx

I see no mention of the %T format specifier.  So I guess, at least
in the msvcrt.dll world, %T is invalid, explaining my result.

 O.S.


Best.


K. Frank

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] End of rubenvb builds

[K. Frank]

Hello Ruben!

OOooohhh  NOoO!!!

On Sun, Jun 23, 2013 at 9:15 AM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 Hi everyone,

 I have come to the conclusion that my MinGW-w64 builds bring too little to
 the table for me to continue maintaining them.

 I strongly encourage you to use the plethora of toolchains in a multitude of
 configurations available at mingw-builds. Comparing download numbers they
 have a much higher visibility, and e.g. their adoption by the Qt Project
 speaks of their quality. They have succeeded in doing what I missed when I
 decided to start building GCC, so my effort spent in doing that is now
 wasted.

 I may dabble into getting Clang 3.3 to work on Windows, perhaps even with
 libc++, but I am not promising anything.

 I'll still linger around here though, don't worry.

Sad to see your builds depart!  (But glad you're staying ...)

Now, I'm sure them mingw-builds builds are fine, and such, but where's a
fellow to go when he wants a nice, WACKY build?  Hmm?

You know, like a fine wine -- maybe a bit off the beaten path, quirky, even,
but a worthy vintage, nonetheless.

Thanks for all your work and all your builds.

 All the best,

 Ruben


Happy Hacking!


K. Frank

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Interest] Several issues compiling Qt 4.8.4 with mingw-w64 4.8.1, possible related to -std=gnu++11

[K. Frank]

Hello Kai!

First off, thanks to Kai and Thiago for their help and support
with this.

Also, I've taken the liberty of cross-posting this to the mingw64
list, just in case anyone over there knows something relevant.

On Tue, Apr 16, 2013 at 9:48 AM, Koehne Kai  wrote:

 -Original Message-
 [mailto:interest-bounces+kai.koehne=digia@qt-project.org] On Behalf
 Of K. Frank

 Hello Kai!
 ...
 First, I understand that Qt's limited usage of the std namespace means
 (hopefully) that it avoids the ABI differences between -std=c++11 and -
 std=gnu++98.

 My concern is the header files.  When I compile my code that uses Qt
 (whether or not the Qt libraries compiled or whether or not there is an ABI
 issue), I include various headers for the Qt features I am using.  I haven't
 traced through which Qt headers include which other Qt headers, but, in
 general, including a top-level user header pulls in a number of supporting
 headers.

 I'm not aware anybody has systematically tried that yet.  If there are 
 issues, _and_ there's an easy, BC compatible fix for it, I'm all for applying 
 it to Qt 4.x.

 Anyhow, in the public Qt API we tend to be pretty conservative  
 well-behaved, so I think there's a fair chance that you'll just be able to 
 compile your stuff . The files you mentioned (HashTable.h and JSImmediate.h) 
 are not part of the  public API.

 Just give it a try and tell us what you find :)

Okay, I will try ...

Just to confirm what the proposal is:

I will build Qt without specifying -std=gnu++11.  That is, I will not
modify qmake.conf, and I will just let configure / mingw32-make
do their things.

When I build my code (which will typically use various c++11 features)
I will specify -std=gnu++11 even though I will be linking to (and using
the headers of) the Qt installation I build without -std=gnu++11.

(I am not actually certain how to do this, but I will ask in a new thread.)

Is that the idea?

I'm not asking for any guarantees -- I understand that I am pushing
the envelope here -- but do folks think that this will probably work
(for some values of probably)?

 Regards

 Kai

Thanks for everyone's advice.


K. Frank

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads testsuite

[K. Frank]

Hello LRN!

On Sun, Apr 14, 2013 at 2:54 AM, LRN ... wrote:
 ...
 This patch should integrate the testsuite imported from pthreads with
 winpthreads.
 ...

Did you ever learn more about  / sort out the create / join race
condition you reported earlier?

(Sorry to semi-hijack the current thread.)

Thanks.


K. Frank

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads testsuite

[K. Frank]

Hi LRN!

On Sun, Apr 14, 2013 at 10:16 AM, LRN  wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 14.04.2013 17:55, K. Frank wrote:
 Hello LRN!

 On Sun, Apr 14, 2013 at 2:54 AM, LRN ... wrote:
 ... This patch should integrate the testsuite imported from
 pthreads with winpthreads. ...

 Did you ever learn more about  / sort out the create / join race
 condition you reported earlier?
 No. Ktietz gave me a patch, but it didn't fix the bug.

 (Sorry to semi-hijack the current thread.)
 One of the reasons why i want testsuite is that create2, in
 particular, fails due to the create/join race. So it's not that bad :)
 ...

How frequently does the race occur?

The reason I ask is that I've used a couple of mingw-w64 builds where
std::thread is implemented on top of winpthreads.  I didn't try any raw
winpthreads create / join tests, but I did do the equivalent at the
std::thread level, namely instantiate / join some std::threads.  When
I ran my elementary (and not particularly high-stress) join tests I didn't
see any problems.  (This was on a two-core windows 7 machine.)

So I'm wondering if the bug you found is relatively rare, or whether I
would need to run a more sophisticated test to catch it.  (Or maybe
whether the specific std::thread use case avoids it somehow.)

Thanks.


K. Frank

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [Interest] Not getting large file support when configuring Qt 4.8.4 for win32-g++-4.6

[K. Frank]

Hello Lists!

I'm am building Qt 4.8.4 with mingw-w64 4.8.1 on a 64-bit windows 7 machine.

(Specifically, qt-everywhere-opensource-src-4.8.4.zip and
x86_64-w64-mingw32-gcc-4.8-stdthread-win64_rubenvb.7z, downloaded
recently.)

When I run configure, specifying -platform win32-g++-4.6, but not specifying
anything about large file support one way or the other, it seems that large file
support is turned off.  The output form configure contains:

   Large File support..no

I am under the impression that configure is supposed to turn on large file
support, based on auto-detected capabilities of the system in question.

One thought that crossed my mind is that maybe 64-bit mingw-w64 no
longer needs special large file support turned on, in that it always has
is, but I couldn't find any commentary to this effect.

Maybe I'm wrong about configure auto-detecting large file support, and I
need to specify it manually.

Or maybe my system is messed up somehow.

Thanks for any advice.


K. Frank

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Interest] Not getting large file support when configuring Qt 4.8.4 for win32-g++-4.6

[K. Frank]

Hi Jon!

On Sun, Apr 14, 2013 at 6:11 PM, JonY  wrote:
 On 4/15/2013 00:46, K. Frank wrote:
 Hello Lists!

 I'm am building Qt 4.8.4 with mingw-w64 4.8.1 on a 64-bit windows 7 machine.

 (Specifically, qt-everywhere-opensource-src-4.8.4.zip and
 x86_64-w64-mingw32-gcc-4.8-stdthread-win64_rubenvb.7z, downloaded
 recently.)

 When I run configure, specifying -platform win32-g++-4.6, but not 
 specifying
 anything about large file support one way or the other, it seems that large 
 file
 support is turned off.  The output form configure contains:

Large File support..no

 I am under the impression that configure is supposed to turn on large file
 support, based on auto-detected capabilities of the system in question.

 One thought that crossed my mind is that maybe 64-bit mingw-w64 no
 longer needs special large file support turned on, in that it always has
 is, but I couldn't find any commentary to this effect.

 Maybe I'm wrong about configure auto-detecting large file support, and I
 need to specify it manually.

 Or maybe my system is messed up somehow.

 Thanks for any advice.

 Is there some sort of log? Hard to tell what configure did to test
 without it.

First, I don't know whether configure does a test.  I saw some online
comments that suggest it does, but nothing definitive.

Second, I don't see anything that looks like a log of tests run by
configure.  (But I certainly don't know where to look.)

Third, the online qt documentation for configure I found was silent
on large file support.

Fourth, running configure --help reports:

   -largefile . Enables Qt to access files larger than 4 GB.

with the -largefile argument not being flagged with a * (default) or
a + (an evaluated default).  So taking this at face value, large
file support is off by default.

Fifth -- and here's where it gets annoying -- I cleaned everything
out and re-ran configure with -largefile specified.  Now configure
claimed that large file support was turned on.  So far so good.

But when I ran the build, I got many copies of the following warning:

   ..\..\..\include/QtCore/../../src/corelib/global/qconfig.h:41:0:
warning: QT_LARGEFILE_SUPPORT redefined [enabled by default]
#define QT_LARGEFILE_SUPPORT 64
^
   command-line:0:0: note: this is the location of the previous definition

And, indeed, the g++ compile command run by the build does
contain:

   -DQT_LARGEFILE_SUPPORT

I guess things are running correctly and these are just annoying
warnings.  But it makes me think that the correct thing to have
done would have been to run configure without -largefile, hopefully
shutting up all the warnings, but having large file support enabled
anyway.

Do any Qt experts know what is going on here?  What's the right
way to build Qt to get large file support?

I'm suspecting that this is a Qt issue, and not specific to mingw-w64.
But I'll take the liberty of leaving it cross-posted to the mingw64 list
for the time being.

Thanks.


K. Frank

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Still seeing the -static issue with Ruben's new 4.8 std::thread-enabled build

[K. Frank]

Hello List and Ruben!

I downloaded Ruben's new std::thread-enabled build, namely:

   x86_64-w64-mingw32-gcc-4.8-stdthread-win64_rubenvb.7z

It reports:
   g++ --version
   g++ (rubenvb-4.8-stdthread) 4.8.1 20130324 (prerelease)

It stills seems to have the -static issue when using std::thread.

Specifically, I have a simple test program that spawns a thread and then
joins it.  If I compile thus:

   g++ -static -std=c++11 -o std_thread_test_a2 std_thread_test_a2.cpp

it runs fine.  If I leave the -static out:

   g++ -std=c++11 -o std_thread_test_a2 std_thread_test_a2.cpp

it crashes, throwing the following error:

   terminate called after throwing an instance of 'std::system_error'
 what():  Enable multithreading to use std::thread: Operation not permitted

This is the same behavior I saw (that I think was recognized as an issue)
with one of Ruben's 4.7 std::thread-enabled builds, namely:

   x86_64-w64-mingw32-gcc-4.7.0-stdthread_rubenvb.7z

Is there any way I can use the std::thread support without linking statically?

Thanks.


K. Frank

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Still seeing the -static issue with Ruben's new 4.8 std::thread-enabled build

[K. Frank]

Hi Ruben!

On Sat, Apr 6, 2013 at 6:25 PM, K. Frank kfrank2...@gmail.com wrote:
 Hi Ruben!

 On Sat, Apr 6, 2013 at 6:21 PM, Ruben Van Boxem
 vanboxem.ru...@gmail.com wrote:
 Op 7 apr. 2013 00:18 schreef K. Frank kfrank2...@gmail.com het volgende:

 Hello List and Ruben!
 ...
 It stills seems to have the -static issue when using std::thread.

 Yes, i forgot to apply the patch circumventing the binutils weak linking bug
 that libstdc++ expects to be functional. My bad.

 I'll try to build a new one tomorrow.

Hey, any chance you could make a build where -std=c++11 is
enabled by default?  Hardly important, but it would be pretty cool ...
(And a public service!)

 ...
 Ruben


Thanks again for all of your builds.


K. Frank

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] New Rubenvb GCC 4.8 std::thread enabled build

[K. Frank]

Hello Ruben!

On Tue, Mar 26, 2013 at 3:02 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 Hi,

 I have uploaded a new GCC 4.8 experimental std::thread build. Nothing
 fundamentally changed since the previous posix-threaded builds.

Yay!  Go Ruben!

 Enjoy,

Well, I'm not sure that enjoy is really the right word ...

 Ruben

Thanks.


K. Frank

--
Own the Future-Intelreg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC 4.8 and -fPIC warning being treated as error

[K. Frank]

Hi Ruben!

On Sat, Mar 23, 2013 at 3:47 AM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 Hi,

 I'm trying to get GCC 4.8 built, ...

Is this a native windows 64-bit 4.8?  Will it have SEH?

Just asking, because (as you know) I am thinking about upgrading, and
am thinking about what stuff it might make sense to wait for.

 Thanks,
 Ruben

Thanks to you for all of your contributions.


K. Frank

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

Re: [Mingw-w64-public] New Rubenvb GC 4.8.0 Personal build

[K. Frank]

Hi Ruben!

Yay!  Go Ruben!

On Sat, Mar 23, 2013 at 12:49 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 Hi everyone,

 I am glad to announce my GCC 4.8.0 build. The 64-bit version uses the new
 seh implementation that replaces sjlj, this means GCC 4.8 is ABI
 incompatible with my other builds. It does mean native Win64 exception
 handling, which is faster than the old sjlj.

Would I be correct in assuming that your build supports std::thread,
and that static linking works with std::thread?

 I regret to say that
 1. LTO is still broken
 2. Ada is still a * to build on Debian stable and not included
 3. Go is also not working on Windows.

(Not issues for me.)

 Other than that, the 4.8 release was built with MinGW-w64 trunk because GCC
 4.8 has some improvements that require this. As it's been pretty stable for
 quite a while, I saw nothing bad in using that.

 You can find the goodies here:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/
 http://sourceforge.net/projects/mingw-w64/files/Toolchain%20sources/Personal%20Builds/rubenvb/release/

 Enjoy,

 Ruben

Thanks again for these builds and all of your efforts.


K. Frank

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

Re: [Mingw-w64-public] New Rubenvb GC 4.8.0 Personal build

[K. Frank]

Hi Ruben!

On Sat, Mar 23, 2013 at 2:45 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 2013/3/23 K. Frank kfrank2...@gmail.com

 Hi Ruben!
 Yay!  Go Ruben!

 On Sat, Mar 23, 2013 at 12:49 PM, Ruben Van Boxem
 vanboxem.ru...@gmail.com wrote:
  Hi everyone,
 
  I am glad to announce my GCC 4.8.0 build. The 64-bit version uses the
  ...
 Would I be correct in assuming that your build supports std::thread,

 No sorry. I'll build an alternate toolchain this week.

Okay, thanks.  I'll keep my eyes open for it.

A quick question:  Just out of curiosity, what would be the benefit of
a build that doesn't have std::thread?  Is there some overhead, or is
the build significantly bulkier?

 ...
 Cheers,

 Ruben

Cheerio!


K. Frank

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

Re: [Mingw-w64-public] New Rubenvb GC 4.8.0 Personal build

[K. Frank]

Ruben -

Thanks.

On Sat, Mar 23, 2013 at 6:48 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 Op 23 mrt. 2013 23:30 schreef K. Frank kfrank2...@gmail.com het
 volgende:

 Hi Ruben!
 ...
  No sorry. I'll build an alternate toolchain this week.

 Okay, thanks.  I'll keep my eyes open for it.

 A quick question:  Just out of curiosity, what would be the benefit of
 a build that doesn't have std::thread?  Is there some overhead, or is
 the build significantly bulkier?

 It makes even C programs depend on the winpthreads library. Although I see
 nothing wrong with a single vs two DLLs you'd need to ship, some people have
 expressed concerns. If you don't need c++11 concurrency, I'd recommend not
 using a posix threading build. But that's just me :-)

Oh, yes.  I remember now seeing that discussion on this list.   Makes sense.

 Ruben

Best.


K. Frank

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

Re: [Mingw-w64-public] [Interest] Compiling Qt (4 or 5) with -std=c++11

[K. Frank]

Hello Ruben!

On Fri, Mar 22, 2013 at 6:22 AM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 2013/3/22 JonY jo...@users.sourceforge.net

 On 3/22/2013 11:26, K. Frank wrote:
 
  If you're interested in a binary compatibility topic that might affect
  you --
  and since you so kindly brought the mingw community in -- be careful
  about the
  C++ exception model from your mingw compiler. They are
  ...
  The MinGW community needs to
  choose
  one model, once and for all, deprecate all others, period. Just choose
  one,
  any one, provided it's not SJLJ. If your compiler uses SJLJ, run from
  it and
  avoid it like the plague. If that's the only option available, choose
  another
  compiler.
 
  Yes, another compatibility issue.  I've been using the dwarf2 version.
 
 Yes, DW2 is quite frankly broken on Windows, since you'll never be able
 to recompile system libraries to be able to throw through it (or 3rd
 party code built with MSVC). It is even more broken on win64.

This is a very real and significant issue, and I would say the word
broken is fully correct.

On the other hand in my use cases I don't normally throw exceptions
through system libraries, and knowing that I can't is a reasonable, if
unsatisfying defense.

 I agree with you, but DW2 isn't broken: the use case of using MSVC-built
 code with MinGW-w64 GCC is not common (it usually is the other way around),
 but it is an (the only?) advantage of SJLJ for x86 Windows. On the other
 hand, the performance penalty is real (I've been notified of this by several
 users) and can be solved by using the dw2 implementation.

Now I'm confused.  Kai said that there's no dw2 for 64-bit mingw-w64.
Your comment sort of implies that there is.

Let me correct myself.  I believe that I am using sjlj.  After all, I have
libgcc_s_sjlj-1.dll in my mingw-w64 bin directory.

Do your comments about using dw2 then only apply to using 32-bit
mingw-w64?

With (pre-4.8) 64-bit mingw-w64, is there a choice other than sjlj that
I can use so I don't have to incur Thiago's wrath?

 For Win64, GCC 4.8 brings the long-needed seh. I doubt anyone will be using
 sjlj on win64 after that.

I will start a new thread, but I do want to ask about 4.8 and what
mingw-w64 build I should upgrade to.

 Ruben

Thanks for everyone's explanations.


K. Frank

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

[Mingw-w64-public] What's a good 64-bit native build to upgrade to?

[K. Frank]

Hello List (and Ruben)!

I am thinking about upgrading my compiler (and various libraries I use).
I am currently using one of Ruben's 64-bit 4.7 builds.

I'm looking for additional c++11 support, keeping, of course, support for
std::thread.  I imagine that 4.8 is the way to go.

My wish list:

   64-bit native windows compiler
   4.7 or better, preferably 4.8
   std:::thread, ideally without the static issue
   compatible with recent Qt source (i.e., either 4 or 5) (I will rebuild Qt)
   relatively stable and bug free

I am not concerned with abi compatibility (other than with c), as I will
plan to rebuild my third-party c++ libraries.

What would people recommend as the best way to go?  Is there anything
on the short-term horizon that I should make a point of waiting for?

Thanks.


K. Frank

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

Re: [Mingw-w64-public] [Interest] Compiling Qt (4 or 5) with -std=c++11

[K. Frank]

Hi Ruben!

Great.  Thanks for clearing things up.

On Fri, Mar 22, 2013 at 10:09 AM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 2013/3/22 K. Frank kfrank2...@gmail.com

 Hello Ruben!
 ...
 No, I never implied such a thing. I was talking about x86 only. There is no
 dw2 for x64 and in all likelihood never will be.

 Let me correct myself.  I believe that I am using sjlj.  After all, I have
 libgcc_s_sjlj-1.dll in my mingw-w64 bin directory.

 Correct.

 Do your comments about using dw2 then only apply to using 32-bit
 mingw-w64?

 Yes.

 With (pre-4.8) 64-bit mingw-w64, is there a choice other than sjlj that
 I can use so I don't have to incur Thiago's wrath?

 No. SJLJ is the only thing that worked. I'm hoping the seh stuff will be
 backported to the 4.7 branch, but maybe that will just incur user
 confusion...
 ...

Thanks,


K. Frank

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

[Mingw-w64-public] [Interest] Compiling Qt (4 or 5) with -std=c++11

[K. Frank]

Hello Lists!

Should I expect to be able to build Qt with -std=c++11 using mingw-w64?

I am considering upgrading the compiler and libraries I use with the specific
goal of using -std=c++11 in order to take advantage of the new c++ features.
(I am hoping to upgrade from gcc 4.7 to gcc 4.8 at the same time.)

As I understand it, using -std=c++11 causes abi breakage, so to do this, I
will have to recompile the various libraries I use.

I have been using one of Ruben's 4.7 std::thread-enabled builds with Qt 4 with
good success (but not with -std=c++11 turned on).  If it makes sense, I would
take this opportunity to upgrade to Qt 5, but I don't view that as essential.

Has anyone built Qt with either gcc 4.7 or 4.8 with -std=c++11 activated?
I've asked about the pros and cons of Qt 4 vs. Qt 5 in a separate post, but
would welcome comments on whether Qt 4 and 5 interact differently with
-std=++11.  (I also use qwt, currently version 6.0.1, but will ask about that
in particular in a separate post.)

Thanks in advance for any advice.


K. Frank

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

Re: [Mingw-w64-public] [Interest] Compiling Qt (4 or 5) with -std=c++11

[K. Frank]

Hi Thiago!

(I've taken the liberty of cross-posting this back to the mingw-w64-public
list.)

On Thu, Mar 21, 2013 at 5:07 PM, Thiago Macieira
thiago.macie...@intel.com wrote:
 On quinta-feira, 21 de março de 2013 16.52.29, K. Frank wrote:
 Hello Lists!

 Should I expect to be able to build Qt with -std=c++11 using mingw-w64?

 No. The Windows headers that are shipped with MinGW aren't standards-
 compliant. You need to compile with -std=gnu++11.

Thank you.  I will bear that in mind.  I don't see any problem with that.

 Qt automatically switches to that mode in the modules that require it.

 As I understand it, using -std=c++11 causes abi breakage, so to do this, I
 will have to recompile the various libraries I use.

 Not with Qt. Qt has the very same ABI, whether you compile it with C++11 or
 C++98.

I guess I should take your word for it.  But I'm a little confused, so let me
ask for some clarification.  How does Qt control the abi produced by the
compiler?  I was under the distinct impression that -std=???11 caused
significant abi breakage, that this was recognized as an issue, but, I
guess, that the gcc folks felt that it was worth it for some reason.

How could Qt manage to dodge that bullet?  Or am I misunderstanding
the issue?

 Has anyone built Qt with either gcc 4.7 or 4.8 with -std=c++11 activated?

 I know someone has, since there have been fixes for MinGW and C++11 mode 
 coming
 in.

 I've been using C++11 and C++0x before that for a couple of years on Linux.
 Since GCC 4.4.

Excellent.

 Thiago Macieira - thiago.macieira (AT) intel.com
   Software Architect - Intel Open Source Technology Center


Thank you for the reassurance.


K. Frank

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

Re: [Mingw-w64-public] [Interest] Compiling Qt (4 or 5) with -std=c++11

[K. Frank]

Hello Christian!

On Thu, Mar 21, 2013 at 5:37 PM, Christian Quast
christian.qu...@cquast-it.de wrote:
 Hi...

 On Thursday 21 March 2013 22:07:54 Thiago Macieira wrote:
 On quinta-feira, 21 de março de 2013 16.52.29, K. Frank wrote:
 [...]
  As I understand it, using -std=c++11 causes abi breakage, so to do
  this, I will have to recompile the various libraries I use.

 Not with Qt. Qt has the very same ABI, whether you compile it with C++11 or
 C++98.

  Has anyone built Qt with either gcc 4.7 or 4.8 with -std=c++11
  activated?
 ...

 I have a project where I use -std=c++11 to compile my code but didn't use it
 to compile Qt 4.8 on windows (on Linux I am using the default opensuse rpms).
 Where ever possible I use C++11 in my code and so far I didn't come across any
 problems.

Thank you.  That's reassuring.

 I am using Ruben's mingw build (x86_64-w64-mingw32-gcc-4.7.2-release-
 win64_rubenvb.7z) if I remember correctly (don't have access to my windows
 machine right now).

Yes, I am also using one of Ruben's 4.7 builds (4.7.0, off the top of
my head).

 Cheers
   Christian

Cheerio!


K. Frank

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

Re: [Mingw-w64-public] [Interest] Compiling Qt (4 or 5) with -std=c++11

[K. Frank]

Hello Ruben!

On Thu, Mar 21, 2013 at 5:37 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:

 Op 21 mrt. 2013 22:31 schreef K. Frank kfrank2...@gmail.com het
 volgende:

 Hi Thiago!
 ...
 On Thu, Mar 21, 2013 at 5:07 PM, Thiago Macieira
 thiago.macie...@intel.com wrote:
  On quinta-feira, 21 de março de 2013 16.52.29, K. Frank wrote:
  Hello Lists!
  ...
  As I understand it, using -std=c++11 causes abi breakage, so to do
  this, I
  will have to recompile the various libraries I use.
 
  Not with Qt. Qt has the very same ABI, whether you compile it with C++11
  or
  C++98.

 I guess I should take your word for it.  But I'm a little confused, so let
 me
 ask for some clarification.  How does Qt control the abi produced by the
 compiler?  I was under the distinct impression that -std=???11 caused
 significant abi breakage, that this was recognized as an issue, but, I
 guess, that the gcc folks felt that it was worth it for some reason.

 How could Qt manage to dodge that bullet?  Or am I misunderstanding
 the issue?

 Different ABI is only problematic if you pass e.g. std::string objects
 across different module ABI boundaries. I suppose Qt avoids using the
 standard library as it provides its own implementations of most if not all
 standard library functionality.

Thank you Ruben, that sounds like the explanation.  Now that I think
about it, I seem to recall the abi breakage being associated with the
standard library.  Certainly having std:;string not work would be
considered pervasive and severe breakage.  But, as you point out, Qt
uses very little (if any) of the template part of the standard library, so
I guess it's a non-issue.


 Ruben

Thanks for the clarification.


K. Frank

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

Re: [Mingw-w64-public] [Interest] Compiling Qt (4 or 5) with -std=c++11

[K. Frank]

Hello Etienne!

On Thu, Mar 21, 2013 at 6:11 PM, Etienne Sandré-Chardonnal
etienne.san...@m4x.org wrote:
 I confirm that compiling a Qt application with -std=gnu++11 while Qt
 was compiled without, works perfectly. This doesn't break the abi. I'm
 also using rubenvb mingw-w64.

Thank you for the confirmation.  It seems to be shaping up as the
consensus that mixing -std=gnu++11 code with non--std=gnu++11
Qt is legitimate and works.

 I could not compile with -std=c++11 as I have math constants such as
 M_PI in many places, but if you really like to, I can do the test.

Thanks for the offer, but please don't take the trouble.  I really don't
have an preference for -std=c++11 over -std=gnu++11, and Thiago
has indicated that -std=gnu++11 is the way to go.

 By the way, since you are using mingw-w64, can you debug properly
 applications in QtCreator?

Sorry, I don't know he answer, as I don't use QtCreator.

 When I debug programs, the call stack is
 empty, while I still can see locals, and when I step out a function,
 the debugger often crashes. I have no such problems with the mingw32
 shipped with Qt.

I have debugged Qt applications with the gdb that came with the gcc
build I used to build Qt and my applications.  Other than some problems
with very slow start-up times, it seems to work.

 Thanks,
 Etienne

I appreciate hearing that this works for you.


K. Frank


 Date: Thu, 21 Mar 2013 16:52:29 -0400
 From: K. Frank kfrank2...@gmail.com
 Subject: [Interest] [Mingw-w64-public] Compiling Qt (4 or 5) with 
 -std=c++11

 Hello Lists!

 Should I expect to be able to build Qt with -std=c++11 using mingw-w64?
 ...

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

Re: [Mingw-w64-public] [Interest] Compiling Qt (4 or 5) with -std=c++11

[K. Frank]

Hello Thiago!

Thank you for the detailed explanation.

On Thu, Mar 21, 2013 at 9:44 PM, Thiago Macieira
thiago.macie...@intel.com wrote:
 On quinta-feira, 21 de março de 2013 17.30.12, K. Frank wrote:
 Hi Thiago!
  ...
  As I understand it, using -std=c++11 causes abi breakage, so to do
  this, I will have to recompile the various libraries I use.
 
  Not with Qt. Qt has the very same ABI, whether you compile it with C++11
  or
  C++98.

 I guess I should take your word for it.  But I'm a little confused, so let
 me ask for some clarification.  How does Qt control the abi produced by the
 compiler?  I was under the distinct impression that -std=???11 caused
 significant abi breakage, that this was recognized as an issue, but, I
 guess, that the gcc folks felt that it was worth it for some reason.

 How could Qt manage to dodge that bullet?  Or am I misunderstanding
 the issue?

 You're misunderstanding the issue.

 The compiler ABI is exactly the same. There has been no change to the calling
 convention or the naming of external symbols (mangling) for existing
 functions. The mangling has new codes so it can support the new C++11 types
 and features (Ds and Di for char16_t and char32_t and support for variadic
 template packs, for example).

 However, Qt is quite clever about the use of such features: those types and
 features only appear in inline functions. Therefore, the external symbols
 exported by Qt are the same, no matter how you compile the Qt libraries.

Thanks.  That's very good to know.

 That's not actually the case if you use Visual Studio, but there the situation
 is completely different. For starters, you can't choose to enable C++11: it's
 always enabled. And second, Microsoft hasn't heard yet about C++ binary
 compatibility. If you upgrade your compiler, you must recompile everything, so
 it doesn't matter which features we use.

Well, for what it's worth, I'm only using mingw / mingw-w64 at the moment.

 You may be actually thinking of some reports that the Standard C++ Library
 that comes with GCC broke compatibility. I've heard the same, and I've also
 heard that it was reverted, or misunderstood. So in the end, I simply don't
 know what the situation is. But it's irrelevant for Qt, since we do not use
 the Standard Library in our public, non-inline functions.

Thank you for explaining that.  I think it was, indeed, the standard
library issue I was remembering.  It probably should have occurred
to me that Qt, being a framework, already has its own versions of
most of the standard library facilities.

 If you're interested in a binary compatibility topic that might affect you --
 and since you so kindly brought the mingw community in -- be careful about the
 C++ exception model from your mingw compiler. They are binary-incompatible
 with one another, if you use exceptions. The MinGW community needs to choose
 one model, once and for all, deprecate all others, period. Just choose one,
 any one, provided it's not SJLJ. If your compiler uses SJLJ, run from it and
 avoid it like the plague. If that's the only option available, choose another
 compiler.

Yes, another compatibility issue.  I've been using the dwarf2 version.
(But there are sjlj advocates out there.)

 Thiago Macieira - thiago.macieira (AT) intel.com
   Software Architect - Intel Open Source Technology Center

Thanks for taking the time to clear these things up.


K. Frank

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

Re: [Mingw-w64-public] Install MinGW w64

[K. Frank]

Hello Jorge!

On Tue, Feb 5, 2013 at 3:31 PM, Jorge F. Hernandez
jor...@fsbcomputers.com wrote:

 By the way,
 ...
 I'm trying to compile libiconv in 64-bit so I can add it as a dependency
 for a PHP I'm building in 64-bit, but libiconv doesn't support VC anymore
 and it asks to use MinGW, but MinGW won't work for me.

 Any ideas?

This doesn't answer your specific question, but you might be able to
use a mingw-w64 pre-compiled 64-bit verions of libiconv.

I faced a similar issue with needing a mingw-w64 version libxml2, and
I didn't want to muck with autotools.  Brian, in an earlier thread on this
list, kindly directed me to:

   http://www.stats.ox.ac.uk/pub/Rtools/R215x.html

You can download:

   http://www.stats.ox.ac.uk/pub/Rtools/goodies/multilib/local215.zip

which contains, among other things, libiconv.

I am successfully using that version of libxml2, and I believe libxml2
depends on libiconv, so I suppose I'm using libiconv, as well.

(These are c, rather than c++ libraries, so my concerns about abi
incompatibilities between various version of mingw-w64 were unlikely
to cause problems, and seem not to have.,)

 Thanks,

 Jorge Hernandez


Good luck.


K. Frank

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Compiling on 64-bit windows

[K. Frank]

Hi Ken!

On Mon, Feb 11, 2013 at 1:12 PM, Ken Goldman kgold...@us.ibm.com wrote:
 I downloaded mingw from mingw.org.  The documentation says:

 The project's name changed from mingw32 to MinGW is to prevent the
 implication that MinGW will only works on 32 bit systems (as 64 and
 higher bit machines become more common, MinGW will evolve to work with
 them).

 What exactly does that mean?  Has it evolved yet?  Can I compile for 64
 bits?  Do I need some other package?  A flag?  Or is mingw not ready yet?

To clear up a possible point of confusion:

mingw and mingw-w64 are two separate projects.

mingw-w64 supports native 64-bit compilation.  niXman's link give
a good introduction on how to do this.  (I have been using Ruben's
builds for some time now to compile natively on 64-bit windows 7.)

At the risk of stating something incorrectly, I believe that the mingw
project intends to support 64-bit compilation at some point in the
future.  As far as I know mingw does not yet support 64 bits (but
I could be out of date).

So I expect that what you downloaded from mingw won't compile
for 64 bits, but if you download from the separate mingw-w64 project,
you will be able to compile for 64 bits.

(By the way, this is the mailing list for the mingw-w64 project.  The
mingw project has a separate mailing list, although a number of
people subscribe to both.)


Good luck.


K. Frank

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Semi-OT: Can one use separate threads for reading and writing a standard winsock socket?

[K. Frank]

Hi Earnie!

On Wed, Feb 6, 2013 at 7:32 AM, Earnie Boyd
ear...@users.sourceforge.net wrote:
 On Tue, Feb 5, 2013 at 8:44 PM, K. Frank wrote:
 Hello List!

 Not really a pure mingw-w64 question, but maybe someone here knows
 the answers.

 Socket connections go two ways -- you can read from and write to them.
 With a standard windows socket, is it safe to use one thread for reading
 and another for writing, or are the reading and writing coupled  somehow
 under the hood?

 Does this help any?
 http://msdn.microsoft.com/en-us/library/windows/desktop/ms684841(v=vs.85).aspx

No, it doesn't really.

It was the Processes and Threads section of 'Dev Center - Desktop:

   Dev Center - Desktop  Docs  Desktop app development documentation
 System Services  Processes and Threads

I clicked around in it some (I didn't read it exhaustively),and didn't
come across any winsock commentary.  (A lot of good stuff on
threads -- I just didn't happen to find the discussion of sockets,
if there is one.)

I did find the following stackexchange topics useful, though:

   http://stackoverflow.com/questions/7418093/use-one-socket-in-two-threads
   
http://stackoverflow.com/questions/1981372/are-parallel-calls-to-send-recv-on-the-same-socket-valid

The consensus seems to be that you can use one thread to read,
and another to write and that the os will take care of any necessary
synchronization.  There was, however, some equivocation, and no
comments specific to windows nor winsock (and some references
specifically to posix).

I'm going to go with the working assumption that I can use two
threads with a winsock socket, but I'll keep my eyes open, just
in case.

 Earnie


Thanks for your reply.


K. Frank

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Semi-OT: Can one use separate threads for reading and writing a standard winsock socket?

[K. Frank]

Hi Kai!

On Wed, Feb 6, 2013 at 9:56 AM, Kai Tietz ktiet...@googlemail.com wrote:
 Streams in binary mode for native Windows sockets? errhh

 Anyway Frank,

 be sure that works.  Sockets are bi-directional and you can write to
 them in one thread and poll for data in another thread without issues.
  I have already done that in the past without issue.

Thanks, great.  That's what it was sounding like, but it's good
to hear it confirmed for winsock.

(By the way, my motivation is that I have some code that reads
from a blocking socket rather than a windows async socket, and
sometimes I want to write to it without waiting for a read to occur.
so my idea is that I can just write with a separate writing thread,
and let the reading thread block.)

 Regards,
 Kai

Thanks for your experience on this.


K. Frank

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Semi-OT: Can one use separate threads for reading and writing a standard winsock socket?

[K. Frank]

Hello List!

Not really a pure mingw-w64 question, but maybe someone here knows
the answers.

Socket connections go two ways -- you can read from and write to them.
With a standard windows socket, is it safe to use one thread for reading
and another for writing, or are the reading and writing coupled  somehow
under the hood?

Thanks.


K. Frank

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Is it safe to mix -std=c++0x and non-c++0x object code?

[K. Frank]

Hello List!

If I have several source files that get compiled to object files and then
linked together to for m an executable, is it safe to compile some
of them with -std=c++0x and others without?

Or does turning on -std=c++0x introduce some kind of abi breakage?

Thanks.


K. Frank

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

Re: [Mingw-w64-public] Is it safe to mix -std=c++0x and non-c++0x object code?

[K. Frank]

Hello Kai and Alexander!

On Mon, Feb 4, 2013 at 11:28 AM, Kai Tietz ktiet...@googlemail.com wrote:
 2013/2/4 K. Frank kfrank2...@gmail.com:
 Hello List!
 ...
 Or does turning on -std=c++0x introduce some kind of abi breakage?
 ...

 Well, there might be troubles by doing so.  There is - IIRC - an
 incompatibility between c++11 and c++98.  So I wouldn't recomment to
 do so in general.

 You might want to read thread
 http://gcc.gnu.org/ml/gcc/2012-06/msg00239.html for getting deeper
 into it.

 Regards,
 Kai

Well, I'm glad I asked, and I'm glad you guys answered.  I think I
will avoid mixing -std=c++0x and non-c++0x for the time being.

You have saved me a big headache and some mysterious (and
futile) debugging sessions.


Thanks for your advice on this.


K. Frank

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

[Mingw-w64-public] [Quickfix-developers] QuickFIX using mingw-w64

[K. Frank]

Hello Lists!

It looks like I've managed to port QuickFIX to mingw-w64.

I haven't run the unit tests (because I didn't have the energy to port
UnitTest++), and I haven't run the acceptance tests (because I didn't
want to deal with the ruby dependency), but I have built a relatively
simple QuickFIX application using my ported library.

Its socket connections work, it runs multiple threads, and it parses
its xml data dictionaries, so the three most platform-dependent pieces
of the system seem, at least on the surface, to be working.

I ended up going with libxml2 (because mingw-w64's msmxl2 seemed
to have some bugs, and, in any event, QuickFIX lists MSXML3 as its
dependency).  I used the pre-built mingw-w64 libxml2 from:

   http://www.stats.ox.ac.uk/pub/Rtools/R215x.html

that Prof Brian Ripley suggested in an earlier thread.  I had had
some concern that a version mismatch between the compiler
used to build libxml2 and the version I'm using might cause an
incompatibility, but then I recalled that libxml2 is a c library, rather
than c++ where such abi breakage would have been more likely.

Most of the porting work involved selectively changing various
#ifdef's dependent on _MSC_VER (not defined by mingw-w64)
to use _WIN32 instead.  There were some minor fixes to
microsoft stuff and a little bit of 64-bit tweakage.

As I said, I don't have any reason to expect my current version
to be bug free, but the basic functionality is there, and I haven't
seen anything break yet.

Thanks for folks suggestions that helped get me going.


Best regards.


K. Frank

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-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] Qt wiki

[K. Frank]

Hi Suresh!

On Sun, Jan 20, 2013 at 5:14 PM, Suresh Govindachar
sgovindac...@yahoo.com wrote:
 ...
Thank you very much for the pre-built packages.  It is only in
the past few days that I heard of Qt, and have started looking
into learning it.

My questions:
 ...

I can't answer your specific questions, but please let me make
two comments:

First, I find Qt to be very good.  I haven't moved to Qt 5.0 yet,
but I have been using Qt 4.8 with mingw-w64 for some time,
and, although nothing is perfect, I find that things work quite
well.  Having said that, Qt does have something of a learning
curve, as will any full-featured gui framework, but if you have
a need for doing gui development, the time it will take to start
learning Qt is time well spent.

Second, Qt has an active and very helpful mailing list:

   Qt-interest inter...@qt-project.org

see:

   http://lists.qt-project.org/mailman/listinfo/interest

You should consider subscribing to that list, and asking your
Qt-specific questions there.

 ...
Thanks,

--Suresh


Happy (Qt) Hacking!


K. Frank

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Dead code path in msxml2.h?

[K. Frank]

Hello List!

It appears that there is a dead code path in msxml2.h that includes a lot of
the important msxml2 stuff.

I am working with Ruben's build:

x86_64-w64-mingw32-gcc-4.7.0-stdthread_rubenvb

downloaded on 9/20/11.

Specifically, line 1805 of msxml2.h:

struct IXMLDOMNamedNodeMap : public IDispatch {

with some more context, for convenience:

   #ifndef __IXMLDOMNamedNodeMap_INTERFACE_DEFINED__
   #define __IXMLDOMNamedNodeMap_INTERFACE_DEFINED__
   EXTERN_C const IID IID_IXMLDOMNamedNodeMap;
   #if defined(__cplusplus)  !defined(CINTERFACE)
   struct IXMLDOMNamedNodeMap : public IDispatch {
   public:
 virtual HRESULT WINAPI getNamedItem(BSTR name,IXMLDOMNode
**namedItem) = 0;

never seems to be processed.

Note, that line 1805 is in the MSXML2 namespace part of msxml2.h because of:

   #ifdef __USE_MSXML2_NAMESPACE__
 namespace MSXML2 {
   #endif

at lines 801-803 of msxml2.h.

I haven't got it all figured out yet, but it appears that this problem
occurs because
msxml2.h includes, indirectly, msxml.h.  Specifically, line 10 of msxml2.h:

   #include rpc.h

indirectly includes msxml.h through the following chain:

rpc.h -- windows.h -- ole2.h -- objbase.h -- urlmon.h -- msxml.h

It appears that msxml.h defines:
__IXMLDOMNamedNodeMap_INTERFACE_DEFINED__

turning off the code path in msxml2.h that includes line 1805.

(msxml.h also defines __IXMLDOMNamedNodeMap_FWD_DEFINED__,
which turns off some other, possibly relevant, code paths.)

Unless there is some macro I need to define before including msxml2.h
that somehow turns off the indirect include of msxml.h or alters the
behavior of msxml.h when it is included, it looks like msmxl2.h is
fundamentally broken, as it, itself, is responsible for including msxml.h,
and therefore ifdef'ing out much of its own code.

(My immediate goal is to get MSXML2::IXMLDOMNamedNodeMap
properly declared and defined, but I think this is only one of several
related problems.)

Any thoughts on what is going on here?  Am I using msxml2.h incorrectly?
Is there perhaps a macro I need to define or some other .h file I need to
include first?

Is this a bug in msxml2.h?  Is there a  work-around?

Thanks for any help with this.


K. Frank.

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] libxml2 with mingw-w64?

[K. Frank]

Ruben -

Thanks for your comments.  Just to follow up a little, below ...

On Wed, Jan 9, 2013 at 1:35 AM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 Op 9 jan. 2013 03:19 schreef K. Frank kfrank2...@gmail.com het volgende:

 Hi Ruben (and Kai)!

 On Tue, Jan 8, 2013 at 1:55 PM, Ruben Van Boxem
 vanboxem.ru...@gmail.com wrote:
  2013/1/8 Kai Tietz ktiet...@googlemail.com
 
  If you don't have them in your include folder, then you might not
  using our headers.
 
  I have msxml.h,  msxml2.h,  msxml2did.h, and  msxmldid.h headers.  You
  should have them too.
 
  I can confirm my 4.7-1-stdthread toolchain has these headers.

 Conversely, do you expect that your 4.7.0 std::thread build did  *not*
 have these headers?  Or should I be surprised that I don't find them,
 and that I somehow screwed up the installation?  (All I did to install
 was unzip:

x86_64-w64-mingw32-gcc-4.7.0-stdthread_rubenvb.7z

 that I downloaded 9/20/2011.)

 Update, please, to something not from the stoneage ;-).

Stoneage?!  Never!  You show yourself disrespect!  This is one of
The Mighty Ruben's 21-st Century Builds!

 The headers should be there, did you check
 mingw64/x86_64-w64-mingw32/include?

My mistake.  The headers are there -- at least:

   msxml.h
   msxml2.h
   msxml2did.h
   msxmldid.h

(When I looked earlier I had mistakenly searched for msmxl
instead of msxml.)  Thanks for letting me know where to look
manually.

 I don't know when these were added, if
 they haven't been present since forever, but 2011 is too old for me to care
 about it :-)

On a separate note, if I want:

   4.7.0 or later -- preferably 4.8
   std::thread enabled
   static issue with std::thread resolved
   native 64-bit windows to 64-bits windows
   strong preference for abi compatibility with my current stoneage build

which build would you recommend?

(Don't stop reading now.  I have a question below.)

 ...
 ...
 If, for practicality, I wish to avoid learning about DCOM, is there any
 simple
 mingw-w64 replacement for the microsoft-world:

#define _WIN32_DCOM
#import msxml3.dll raw_interfaces_only named_guids
using namespace MSXML2;

 I imagine that the rest of the quickfix could then accesses msxml in
 relatively
 standard c++ (i.e., without microsoft extensions) that should be
 compilable
 by mingw-w64.

 I imagine this is all C, not C++. Nevertheless, QuickFix should wrap this
 stuff anyway. You should be able to not case about its dependencies when
 writing code that uses it.

I agree with this.  QuickFIX has wrapped the calls to msxml, and
I think that unless I try to modify the xml stuff, it should just work,
and I shouldn't have to care.

I am hoping that all I need to do is translate the above code
fragment, e.g.:

   #import msxml3.dll raw_interfaces_only named_guids

into the mingw-w64 world (without learning DCOM).

Any suggestions or even educated guesses would be helpful.
Should I just #include all four msxml headers?  Include only
one master header file?  Something else?  Might I have to
manually add some msxml library to the link command?

I'm speculating that the microsoft #import command is reading
through the .dll to find and extract the function-prototype information
that in the mingw-w64 world is in the #include header files.  But
that's just a guess, so any help would be appreciated.

Again, I'm not asking how to use msxml.  I just need to know how
to make msxml available to code that presumably already uses it
correctly by finding the mingw-w64 equivalent of the #import line.


 Ruben


Thanks again.


K. Frank

--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] libxml2 with mingw-w64?

[K. Frank]

Brian -

Thank you for your response.

On Tue, Jan 8, 2013 at 11:14 AM, Prof Brian Ripley
rip...@stats.ox.ac.uk wrote:
 On 08/01/2013 15:24, K. Frank wrote:
 ...
 Great.  If I end up needing libxml2, I'll plan to build it myself.

 Do you happen to know if I should expect the build to be
 totally straightforward (with mingw-w64)?  Any gotcha's or
 dependencies I should be expecting?

 It's 'totally straightforward'.  Well, at least if you cross-compile it from
 a platform with a full set of tools (I use x86_64 Linux).

 You could pick up a pre-built version from
 http://www.stats.ox.ac.uk/pub/Rtools/R215x.html (note the packaging uses
 lib/i386 and lib/x64).

First let me ask about the pre-built version:

Unzipping local215.zip, I see a file, libxml2.a, in the lib\x64 directory.
Is this a static library, i.e., a non-dll archive?  Is this the thing I get
when I run the ar.exe (distributed, for example, with Ruben's build)?

The web page you linked to says that the tools are based on mingw-w64,
gcc 4.6.3.  Would you or others have any expectation as to whether they
(in particular libxml2) would be abi-compatible with the std::thread-enabled
4.7.0 build of Ruben's that I am using?

Both you and Pavel have talked about cross-compiling libxml2.  For
better or for worse, I am not currently set up to do that. Would it be
realistic to expect to be able to compile libxml2 natively, i.e., fire up
the above-mentioned Ruben's native mingw-w64 build to build it?

If the various autotools are the only sane way of building libxml2,
what role might msys play?  I'm a little fuzzy on msys, never having
used it.  Would building libxml2 under msys count as a native build?
Could I continue using Ruben's build of gcc?  Or would using msys
put me into cross-compilation land and/or produce an msys version
of libxml2 that won't work on plain windows?

Lastly, if msys is an option, has anyone actually built libxml2 under
msys using mingw-w64?

(I will follow up on Pavel's comments about msxml by starting a
new msxml thread, and try to keep this thread focused on
libxml2.)

 --
 Brian D. Ripley,  rip...@stats.ox.ac.uk
 Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/


I appreciate your suggestions and your help.


K. Frank

--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] msxml with mingw-w64 (for QuickFIX) (was: libxml2 with mingw-w64?)

[K. Frank]

Hi Pavel (and List)!

(Since my follow-up to Pavel's comments are about msxml, I am starting
a new thread here to separate the discussion from that about libxml2.)

On Wed, Jan 9, 2013 at 8:48 AM, pavel ... wrote:
 Frank, see my comments bellow.

 On Wed, 2013-01-09 at 08:04 -0500, K. Frank wrote:
 I am hoping that all I need to do is translate the above code
 fragment, e.g.:

#import msxml3.dll raw_interfaces_only named_guids

 into the mingw-w64 world (without learning DCOM).

 Any suggestions or even educated guesses would be helpful.
 Should I just #include all four msxml headers?  Include only
 one master header file?  Something else?  Might I have to
 manually add some msxml library to the link command?

 I'm speculating that the microsoft #import command is reading
 through the .dll to find and extract the function-prototype information
 that in the mingw-w64 world is in the #include header files.  But
 that's just a guess, so any help would be appreciated.

 Again, I'm not asking how to use msxml.  I just need to know how
 to make msxml available to code that presumably already uses it
 correctly by finding the mingw-w64 equivalent of the #import line.


 MS #import command does not read in the .dll. It reads in a binary file
 called type library, usually with extension .tlb (however, the type
 library can be also linked as resource to any executable file, e.g. exe,
 dll and ocx). There is public API for reading type libraries, so
 virtually a support for #import could be implemented into MinGW, but I
 am afraid that it would be quite a big job.

 You don't need to link any COM dll, it is useless. On the other hand,
 you must link to ole32 (defines CoInitialize, CoUninitialize), oleauto32
 (defines CoCreateInstance) and possibly uuid (defines GUID_NULL). Then
 you must call CoInitialize in the beginning of your code (definitively
 prior trying to load a COM object) and call CoUninitialize in the end of
 your application. This all is perhaps handled by the MS _WIN32_DCOM
 definition, I am not sure.

 You then create a new instance of a COM object by calling the
 CoCreateInstance function with appropriate arguments.

Thank you for the overview.  I do have a cartoon picture of how COM
works, but nothing really more than that.

I do see in the msxml.h file provided by mingw-w64 declarations of
various xml interfaces.  I'm guessing that's effectively the information
that visual studio gets with its #import command.

In the QuickFIX code (in MSXML_DOMDocument.cpp, for those who
care) I see the following code:

  MSXML_DOMDocument::MSXML_DOMDocument() throw( ConfigError )
  : m_pDoc(NULL)
  {
if(FAILED(CoInitializeEx( 0, COINIT_MULTITHREADED )))
  if(FAILED(CoInitializeEx( 0, COINIT_APARTMENTTHREADED )))
throw ConfigError(Could not initialize COM);

HRESULT hr = CoCreateInstance(
  MSXML2::CLSID_DOMDocument, NULL, CLSCTX_ALL, __uuidof(
MSXML2::IXMLDOMDocument2 ),
  ( void ** )  m_pDoc );

if ( hr != S_OK )
  throw( ConfigError( MSXML DOM Document could not be created ) );
  }

Maybe I'm being too optimistic, but I see the QuickFIX code calling
CoInitialize and CoCreate, and so on.  So I'm hoping that all of the
COM stuff is already taken care of in the QuickFIX code, *if* *only*
I can figure out how to translate the

   #define _WIN32_DCOM
   #import msxml3.dll raw_interfaces_only named_guids
   using namespace MSXML2;

that appears in stdafx.h into mingw-w64 land (and get it out of
stdafx.h).

Is it reasonable to imagine #include'ing msxml2.h (or maybe
some of the other mingw-w64-provided msxml headers) into
the .cpp file in question (MSXML_DOMDocument.cpp)?

I should mention that the file in questions also includes:

   #include atlbase.h
   #include atlconv.h

which I recall hearing somewhere are COM-related.

To summarize, I don't know what I'm doing with COM, so I'm looking
for a recipe.

I am hoping that I can:

   1)  include one or more of the mingw-w64 msxml headers in the
file in question.

   2)  link to (following what Pavel said) ole32, oleauto32, and possibly uuid

   3)  remove the non-standard #import directive

Could this work?  If it's close, are there a couple of other details I need
to add?

Or am I all wet here and the only way to port (the msxml part of) QuickFIX
to mingw-w64 would be to re-write it?

 Pavel


Thanks for any further advice.


K. Frank

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] libxml2 with mingw-w64?

[K. Frank]

Hello List!

I'm under the impression that libxml2 works (can be made to work)
with mingw-w64, but that it does not come with mingw-w64 out of
the box.

Is this correct?

If so, what is the best / easiest way to get libxml2 going with the
mingw-w64 version I have (one of Ruben's std::thread-enabled builds)?

(For those who care, this is a follow-up to the questions I was asking
about building quickfix.  As I understand it, quickfix requires xml,
either libxml2 or msxml.  I am assuming -- perhaps incorrectly -- that
because I am using mingw-w64 rather than visual studio, the msxml
approach is not for me.  But if I'm wrong about msxml with mingw-w64
(or about quickfix and xml), please chime in.

As an update on quickfix, I have been putting together a makefile by
hand.  So far I haven't hit any makefile issues -- all the work has been
tracking down the various linux / windows issues.  As expected, most
of the fixes involve changing some of the occurrences of _MSC_VER
to _WIN32.  So far, it's been relatively straightforward, but a certain
amount of donkey work.)


Thanks for any suggestions.


K. Frank

--
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] libxml2 with mingw-w64?

[K. Frank]

Hi Jon!

On Tue, Jan 8, 2013 at 9:23 AM, JonY jo...@users.sourceforge.net wrote:
 On 1/8/2013 21:30, K. Frank wrote:
 Hello List!

 I'm under the impression that libxml2 works (can be made to work)
 with mingw-w64, but that it does not come with mingw-w64 out of
 the box.

 Is this correct?

 That is right, libxml2 is unrelated to mingw-w64, so there is no bundle
 for it.

 If so, what is the best / easiest way to get libxml2 going with the
 mingw-w64 version I have (one of Ruben's std::thread-enabled builds)?

 Yes, you can use Ruben's GCC builds to build them. At the moment, they
 are the recommended downloads if you want to run GCC on Windows without
 MSYS or Cygwin.

Great.  If I end up needing libxml2, I'll plan to build it myself.

Do you happen to know if I should expect the build to be
totally straightforward (with mingw-w64)?  Any gotcha's or
dependencies I should be expecting?

 On the side note, std::thread builds make pthread necessary, I'm not
 sure how you feel about adding dependencies.

I'm okay with that.  I believe that Ruben's std::thread-enabled
build came bundled with winpthreads, and, as I understand it,
winpthreads is the mingw-w64's officially supported method
for supporting std::thread.

If I end up getting quickfix to work and end up actually using it
I will build it into my stuff, and I've pretty much switched over to
std::thread for my own threading purposes, so Ruben's build
(with the winpthreads dependency) is what I would be using.

 (For those who care, this is a follow-up to the questions I was asking
 about building quickfix.  As I understand it, quickfix requires xml,
 either libxml2 or msxml.  I am assuming -- perhaps incorrectly -- that
 because I am using mingw-w64 rather than visual studio, the msxml
 approach is not for me.  But if I'm wrong about msxml with mingw-w64
 (or about quickfix and xml), please chime in.

 Not really, msxml may work out of the box with mingw-w64 if the headers
 are already deciphered by the developers. If it comes out of the box
 with Windows or Visual Studio, chances are it is already in mingw-w64.

Ah, okay.  I will see if I can get the msxml version of quickfix to build.
Would you happen to know if a stock windows 7 would come with
msxml (or how I can check), or whether I would need  visual studio
or a separate msxml download?  Also, I think I searched the mingw-w64
source for things that look like msxml, and came up empty.  Would you
happen to know whether I should expect mingw-w64 to have the msxml
headers, or how I might check (short of trying the build)?

I can probably sort these things out myself, but if you happen to
know, it would save me a little time, and give me a sense of what
I might expect.


Thanks for your help.


K. Frank

--
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] libxml2 with mingw-w64?

[K. Frank]

Kai -

Thanks for your response.

On Tue, Jan 8, 2013 at 10:57 AM, Kai Tietz ktiet...@googlemail.com wrote:
 2013/1/8 K. Frank kfrank2...@gmail.com:
 Ah, okay.  I will see if I can get the msxml version of quickfix to build.
 Would you happen to know if a stock windows 7 would come with
 msxml (or how I can check), or whether I would need  visual studio
 or a separate msxml download?  Also, I think I searched the mingw-w64
 source for things that look like msxml, and came up empty.  Would you
 happen to know whether I should expect mingw-w64 to have the msxml
 headers, or how I might check (short of trying the build)?

 msxml is supported by Windows 7,  At least on my Win7 box I see
 msxml3, msxml4, msxml3r, msxml4a, msxml4r, msxml6, and msxml6r DLLs.
 So yes, they are there.

Okay.  I see, for example, msxml4.dll.  It's in the directory:

   
C:\Windows\winsxs\x86_microsoft.msxml2_6bd6b9abf345378f_4.20.9818.0_none_b7e811947b297f6d

 We support this interface ... see the msxml*.h headers.  By the way
 msxml-stuff is DCOM, therefore you will search without luck the
 msxml.dll ;)

I don't see any msxml headers.

I do, for example, see winsock2.h is the directory:

   
.\x86_64-w64-mingw32-gcc-4.7.0-stdthread_rubenvb\mingw64\x86_64-w64-mingw32\include

(As you can see, I am using one of Ruben's 4.7.0,
std::thread-enabled builds.)

Am I looking for the mingw-w64 msxml headers in the wrong
place?  Am I missing them in the specific build (Ruben's)
that I'm using, but you have them in other builds?

I haven't tried building the msxml flavor of quickfix yet.  But I
do see how it references msxml.  So far all I have found is:

   #define _WIN32_DCOM

   #import msxml3.dll raw_interfaces_only named_guids
   using namespace MSXML2;

(I haven't found any references to msxml headers.)

I'm assuming that this #import stuff is microsoft-specific, and
won't work with mingw-w64.  But please let me know if I'm
wrong about this.

 Regards,
 Kai


Thanks very much for your help with this.


K. Frank

--
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] libxml2 with mingw-w64?

[K. Frank]

Pavel -

Thanks for your reply.

On Tue, Jan 8, 2013 at 1:12 PM, pavel pa...@pamsoft.cz wrote:
 On Tue, 2013-01-08 at 10:24 -0500, K. Frank wrote:

 Great.  If I end up needing libxml2, I'll plan to build it myself.

 Do you happen to know if I should expect the build to be
 totally straightforward (with mingw-w64)?  Any gotcha's or
 dependencies I should be expecting?

 I have cross-compiled libxml2 from Debian recently without any issues.
 I've used Ruben's personal build and compiled zlib, libffi, libiconv and
 libxml2 in this order. I am not sure whether libffi and libiconv is
 required by libxml, I needed them for some other stuff.

That's good to know.  It sounds like it should be possible for me
to use the libxml2 approach, if need be.

 zlib cannot be configured for cross-compilation (or at least I heven't
 managed that), Makefile.gcc should be used instead for direct
 compilation. I can attach the whole script for compilation, if it helps.

 libffi, libiconv and libxml2 can be easily configured with the
 following:

 ./configure --host=i686-w64-mingw32 \
 --build=x86_64-unknown-linux-gnu \
 --prefix=/home/pavel/Programs/local32

 It works the same for 64bit Windows with -host=x64_86-w64-mingw32

 HTH, Pavel


Yes, thanks.  I will keep this in mind when I return to libxml2.


K. Frank

--
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] libxml2 with mingw-w64?

[K. Frank]

Hi Ruben (and Kai)!

On Tue, Jan 8, 2013 at 1:55 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 2013/1/8 Kai Tietz ktiet...@googlemail.com

 If you don't have them in your include folder, then you might not
 using our headers.

 I have msxml.h,  msxml2.h,  msxml2did.h, and  msxmldid.h headers.  You
 should have them too.

 I can confirm my 4.7-1-stdthread toolchain has these headers.

Conversely, do you expect that your 4.7.0 std::thread build did  *not*
have these headers?  Or should I be surprised that I don't find them,
and that I somehow screwed up the installation?  (All I did to install
was unzip:

   x86_64-w64-mingw32-gcc-4.7.0-stdthread_rubenvb.7z

that I downloaded 9/20/2011.)

 Ruben


 The code-sniplet you've shown is a ource using VC's private extensions
 in #C(++). Gcc doesn't support #C(++).
 About how to use DCOM-Objects, I would recomment a book like

 http://www.amazon.com/Professional-DCOM-Programming-Richard-Grimes/dp/186100060X
 or take a look to

 http://www.codeproject.com/Articles/666/DCOM-D-Mystified-A-DCOM-Tutorial-Step-1
 link.

If, for practicality, I wish to avoid learning about DCOM, is there any simple
mingw-w64 replacement for the microsoft-world:

   #define _WIN32_DCOM
   #import msxml3.dll raw_interfaces_only named_guids
   using namespace MSXML2;

I imagine that the rest of the quickfix could then accesses msxml in relatively
standard c++ (i.e., without microsoft extensions) that should be compilable
by mingw-w64.

 Regards,
 Kai

Thanks again for everyone's help.


K. Frank

--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Mingw-users] Thoughts on how to build a linux / visual studio project (QuickFIX) with mingw

[K. Frank]

Hi Ruben (and Peter) -

First, thanks to everyone for their comments.  This discussion has
been very informative and helpful.

Before commenting inline, below, please let me semi-hijack this
section of the thread with a comment to Peter:  I've downloaded
(but not yet installed) CodeLite, and have been browsing the
online documentation.  I don't yet see a discussion of how to
import / translate a visual-studio solution file.  Could you point
me to a section of the documentation that covers this (or maybe
the right button to click on the CodeLite application)?

(I've also recopied this post to the mingw-users list, because
I think that was the list Peter was using.)

On Sun, Jan 6, 2013 at 7:55 AM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 2013/1/6 JonY jo...@users.sourceforge.net

 On 1/6/2013 18:54, Kai Tietz wrote:

  I'm thinking (perhaps wrongly) that if I start with the unix
  configure
  script, I'll be more likely to get bumped over into unix-style,
  pthreads
  and posix sockets land, where if I start on the visual studio side, I
  might be more likely to end up with windows threading and winsock.
  (Just a hope.)
  ...

 To get this thread back on-topic and to prove my point (even with autotools
 if you didn't have a platform in mind it probably won't work out of the
 box), I tried the quickfix autotools and got (the half-expected):

For my education, what specific autotools command line did you type?
Something like:

   ./configure --host=x86_64-w64-mingw32  make  ?

Did you run it on linux or under msys?


 libtool: compile:  x86_64-w64-mingw32-g++ -DHAVE_CONFIG_H -I.
 -I/m/Development/Source/quickfix/src/C++/test -I../../.. -I..
 -I../../../UnitTest++/src -g -O2 -Wall -ansi -Wpointer-arith -Wwrite-strings
 -I/libxml/include/libxml2 -O0 -g -MT DictionaryTestCase.lo -MD -MP -MF
 .deps/DictionaryTestCase.Tpo -c DictionaryTestCase.cpp  -DDLL_EXPORT -DPIC
 -o .libs/DictionaryTestCase.o
 In file included from ../Exceptions.h:27:0,
  from ../Dictionary.h:31,
  from DictionaryTestCase.cpp:28:
 ../Utility.h:71:24: fatal error: sys/socket.h: No such file or directory
  #include sys/socket.h
 ^
 compilation terminated.

Is the output of the configure step a relatively straightforward
makefile (i.e., not too many layers of variables or sub-makefiles)?
If so, may I ask you to email me a copy?

Because the linux and windows source distributions are the
same (at least as far as I can tell), I think if I have a plain-vanilla
makefile, I'll be able to tweak the #ifdef's in the source or maybe
the predefined preprocessor macros passed in to the compiler,
and get things to work.

The code isn't that bad.  The only unix / windows differences
that I've come across are sockets, threads, and the stdafx.h
stuff, so I think I should be able to sort things out.

 To Frank: I suggest writing some kind of build script or file from the VC
 project files, which have a high chance of having all the Windows stuff set
 right. Remember to drop stdafx.h and mind specific defines and such that
 would signify the exclusion of the Unix code.

Yes, that is my current plan of action, trying to leverage the CodeLite
solution-file translation that Peter mentioned.

 Hope this helps,

Very much so.

 Ruben
 ...


Thanks for everyone's help.


K. Frank

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Mingw-users] Thoughts on how to build a linux / visual studio project (QuickFIX) with mingw

[K. Frank]

 resources for autotools:
 http://sourceware.org/autobook/
 http://www.lrde.epita.fr/~adl/dl/autotools.pdf
 http://www.flameeyes.eu/autotools-mythbuster/
 https://www.gnu.org/software/autoconf-archive/

 There's also a book you can buy:
 http://nostarch.com/autotools.htm

Perhaps you'll make an autotools connoisseur out of me yet.

 Finally, I recommend console2 for any MSYS work. It's really good.
 http://sourceforge.net/projects/console/

 Good luck,

 Ray.
 ...


Thank you.  I appreciate everyone's suggestions and help.


K. Frank

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [Quickfix-developers] [Mingw-users] Re: QuickFIX under MinGW

[K. Frank]

Hi Sergio!

Thanks for your reply and the very interesting data point that
you've got this working.

I am taking the liberty of copying this to the QuickFIX, mingw,
and mingw64 lists.

On Sun, Jan 6, 2013 at 11:33 AM, Info i...@matear.eu wrote:

 Ciao Frank.

 Any update/news on this issue? I'm a MinGW user and no problem building
 it.

I'm plodding ahead, and I think I understand the basic issues,
but I haven't built QuickFIX yet.

Do I understand your comment correctly that you have built
QuickFIX with mingw?

If so, could you let me know how you did it?  I'm not looking
for a detailed step-by-step recipe (at least not initially), but
your basic approach.  Did you set up a makefile by hand?
Did you run autotools under msys and it worked out of the
box?  Did you cross-compile on linux?  Etc., etc.?

Thanks for any pointers on the best way to proceed.

 Cheers.

 Sergio.

And a hearty Ciao Sergio to you!


K. Frank


  Original Message 
 Subject: Re: [Mingw-users] [Mingw-w64-public] Thoughts on how to build a
 linux / visual studio project (QuickFIX) with mingw
 Date: Sun, 6 Jan 2013 09:15:26 -0500
 From: K. Frank kfrank2...@gmail.com
 Reply-To: MinGW Users List mingw-us...@lists.sourceforge.net
 To: mingw-w64-public@lists.sourceforge.net
 CC: MinGW Users List mingw-us...@lists.sourceforge.net

 Hi Ruben (and Peter) -

 First, thanks to everyone for their comments.  This discussion has
 been very informative and helpful.
 ...

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Quickfix-developers] [Mingw-users] Re: QuickFIX under MinGW

[K. Frank]

Hello Sergio!

On Sun, Jan 6, 2013 at 2:04 PM, Info i...@matear.eu wrote:
 I am taking the liberty of copying this to the QuickFIX, mingw,
 and mingw64 lists.

 No worries. I hope they're interested!

 Do I understand your comment correctly that you have built QuickFIX with
 mingw?

 QuickFIX builds fine under MinGW!

Excellent!  Now if I can only learn how to do it.

  If so, could you let me know how you did it?

 The same way as you would build any other app: configure --prefix=/mingw
 . then: make   then: make install

I have a couple of questions about this:

According to Ruben's post in a sister thread on the mingw-w64-public
list:

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

it seems that the configure / make approach doesn't work out of the
box.  Also, looking at the source code it seems that it won't / can't
work (see various comments in the thread), at least not without
modifying the source.

What, specifically did you do to get it to work?

Obviously, if I type configure in a plain-vanilla windows command
prompt, nothing will happen, because windows doesn't have a
configure command and doesn't recognize unix shell scripts.

So, did you cross-compile under linux?  Did you run configure
under msys?  Something else?

When you built QuickFIX under mingw, from where did you get
the source?  I got my source directly from www.quickfixengine.org,
see:

   http://www.quickfixengine.org/download

Did you have to modify the source at all to get it to compile with
mingw?

 Can you advise a 'proper' way of testing it once we have the binaries?

Once we have the binaries?  I thought you already had the binaries,
because you've built QuickFIX with mingw.  Or did you mean something
else?

As for testing, the source distribution I downloaded (see above)
comes with both c++ unit tests that I suppose are build targets
in the unix-style makefile and/or the visual-studio solution file.

There are also ruby-driven (so for this piece there is a ruby
dependency, and you have to install ruby) acceptance tests.

So my speculation is that one proceeds as follows:

   1)  build QuickFIX  --  no error?  good.
   2)  run unit tests -- tests pass?  better.
   3)  run acceptance tests -- test pass?  best!

To me it seems sensible that the proper way of testing is to
run the test suites that come with the distribution.

 Cheers.

 Sergio.

Thanks for following up;.


K. Frank

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Mingw-users] Thoughts on how to build a linux / visual studio project (QuickFIX) with mingw

[K. Frank]

Hello Ruben and All!

On Sat, Jan 5, 2013 at 5:36 AM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 2013/1/4 K. Frank kfrank2...@gmail.com

 Hi Lists!

 What are people's thoughts on porting a linux / visual studio
 project to mingw and / or mingw-w64?

 I had asked earlier whether anyone had built QuickFIX with mingw
 and / or mingw-w64.  I conclude from the relative silence that mingw
 is not directly supported by the QuickFIX project, and that no one
 has really tried or succeeded in building QuickFIX with mingw.
 ...
 3) Try to run the linux configure script -- maybe with msys -- to
 get a mingw32-make-compatible makefile, or at least a makefile
 than can be used as a starting point.  My concern here is that
 doing so would put the configure script into linux mode and
 would trigger the use of various linux-specific code (e.g., posix
 sockets).

 If it's a decent configure script, passing --host=i686-w64-mingw32 or
 --host=x86_64-w64-mingw32 should work just fine. If there's a configure
 script present, try using that. It cannot be used to get a mingw32-make
 compatible makefile.

Please let me respond both to Ruben's and earlier comments:

Initially I would like to just get QuickFIX built and play around
with it.  I may or may not end up having a long-term interest in
it.  So for the time being I do not think that I would want to invest
the effort into adding mingw support to the autotools build
process (unless it were already almost there).

Also, it probably wouldn't make much sense in adding formal
mingw support to QuickFIX unless the QuickFIX project were
interested in upstreaming the changes.  Based on the relative
lack of response to my inquiry on the QuickFIX list and the
fact that I've only seen a small handful of questions over the
past five years about whether QuickFIX can be built with mingw,
I'm guessing that there would be little interest in the QuickFIX
community for supporting mingw.

To respond to Ruben's and Eli's comments:

I don't currently have msys or a unix emulator set up.  So the
suggestion to try out the configure script just to see involves
a little more work than just trying it out.

To Ruben's comment:  Is there some way I can check whether
the configure script claims to support mingw?  Should I expect
the character string for the host (e.g.,  i686-w64-mingw32) to
reside somewhere in the script itself?  Is there some database
file of supported hosts used by the scripts that I could search
for variations of mingw?  I'd like to have some expectation that
the configure script supports mingw before I go hunt down a
linux system or unix emulator.

As for Peter's suggestion, I will check out CodeLite.  If it doesn't
look too painful, I'll try translating the solutions file into a makefile.
I'm thinking (perhaps wrongly) that if I start with the unix configure
script, I'll be more likely to get bumped over into unix-style, pthreads
and posix sockets land, where if I start on the visual studio side, I
might be more likely to end up with windows threading and winsock.
(Just a hope.)

 ...
 So, I'm not asking for a recipe to build QuickFIX in particular.
 Rather, I'm hoping for some wisdom on how to port a relatively
 clean, cross-platform (joint linux / visual studio) project to mingw,
 and on what tricky points I might encounter when doing so.

 Thanks for any advice.

 K. Frank


Thanks to All for your comments.  I'll report back if I learn anything
useful.


K. Frank

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [Mingw-users] Thoughts on how to build a linux / visual studio project (QuickFIX) with mingw

[K. Frank]

Hi Lists!

What are people's thoughts on porting a linux / visual studio
project to mingw and / or mingw-w64?

I had asked earlier whether anyone had built QuickFIX with mingw
and / or mingw-w64.  I conclude from the relative silence that mingw
is not directly supported by the QuickFIX project, and that no one
has really tried or succeeded in building QuickFIX with mingw.

So I thought I might try doing so myself.

I see three ways to proceed:

1) Start with the actual source (i.e., .cpp files, etc.) and put
together my own mingw32-make-compatible makefile.  I think
this should be relatively straightforward, but tedious, and would
presumably represent duplicated effort.

2) Try to translate a visual studio solution file into a makefile.
First, I don't know how to go about doing so (solution files are
rather different than makefiles), and second, doing so might
trigger visual-studio-specific features (e.g., .stdafx.h files).

3) Try to run the linux configure script -- maybe with msys -- to
get a mingw32-make-compatible makefile, or at least a makefile
than can be used as a starting point.  My concern here is that
doing so would put the configure script into linux mode and
would trigger the use of various linux-specific code (e.g., posix
sockets).

In a sense getting QuickFIX to build with mingw shouldn't be too
hard.  It is already written in relatively portable, non-microsofty
c++ (because it builds on the linux side), but can be built as a
native windows application (because it builds on the visual studio
side).

My problem is that the build process is encoded, on the one hand,
in automake configure  make scripts, and on the other hand,
in visual studio solution files.

QuickFIX offers both linux and windows distributions.  The source
code in the two distributions is identical.  (At least as far as I can
tell.  It's certainly nearly identical.)  The linux / windows differences
reside in #ifdef'ed sections of the joint code base, and the most
notable differences I have come across are (not surprisingly) posix
sockets vs. winsock.

So, I'm not asking for a recipe to build QuickFIX in particular.
Rather, I'm hoping for some wisdom on how to port a relatively
clean, cross-platform (joint linux / visual studio) project to mingw,
and on what tricky points I might encounter when doing so.

Thanks for any advice.


K. Frank

--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [Quickfix-developers] [Mingw-users] QuickFIX with mingw / mingw-w64?

[K. Frank]

Hello Lists!

Has anybody built QuickFIX with mingw or mingw-w64?

Would anybody have thoughts on what tweaks might be
necessary to do so?

(I asked this question a few years back on the QuickFIX list,
and at that time the answer seemed to be pretty much no, but
I thought I'd ask again to see if anybody has experimented in
the meantime with QuickFIX using mingw / mingw-w64.)

Thanks for any information.


And to all my List Colleagues:  Happy New Year!


K. Frank

--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 
___
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

[K. Frank]

Hi Jim!

On Sun, Nov 11, 2012 at 1:32 AM, Jim Michaels jmich...@yahoo.com wrote:
 comeau didn't compile it either.

If Comeau didn't compile it (nor did gcc), in all probability it's illegal code
on your part.  (I've never caught Comeau up in a mistake, although I'm
sure the language lawyers out there could if they tried hard enough.)

 I have no other compiler then gcc right now. my other compilers are so old
 they are useless.
 however, I am reworking the code to use indexes instead. it's harder and
 more error-prone because I don't remember how the code works. I still think
 c++ should have iterator references or some kind of ability to pass
 iterators back through a function to save us all headaches. I consider that
 basic functionality. :-(

There are several thoughtful c++ experts on comp.lang.c++.moderated,
and one guy in particular who has participated heavily in the standards
process.  They could probably give you some sense of whether iterator
references are a bad idea (and why), or whether they're potentially a
good idea, but what issues might be keeping them out of the language.

Or, as Ruben suggested, if you prefer the forum format to news groups,
you could look at stackoverflow.com.  Not a criticism, but stackoverflow
is more generally about programming, and not narrowly focused on c++.
(But c++-specific questions fall well within their charter.)

 thanks for the pointers though. :-]

 Jim Michaels


Happy Hacking!


K. Frank


 
 From: K. Frank kfrank2...@gmail.com

 Hi Jim!
 ...

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

[K. Frank]

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