On Wed, May 9, 2012 at 6:14 PM, Jonathan Wakely wrote:
> On 9 May 2012 20:49, Kai Tietz wrote:
>>
>> The issue about critical-sections and gthread (and also pthread) API
>> is, that not all locking-kinds can be modelled by it. The difference
>> on Windows for it is, that a critical section object
On 9 May 2012 20:49, Kai Tietz wrote:
>
> The issue about critical-sections and gthread (and also pthread) API
> is, that not all locking-kinds can be modelled by it. The difference
> on Windows for it is, that a critical section object provides
> synchronization similar to that provided by a mute
On 9 May 2012 20:06, K. Frank wrote:
> However, as noted in my previous post, I have happily done some
> (limited) windows-api threading programming with Ruben's build
> (and also did the windows-api threading programming necessary
> to implement ),
If you use GCC built with --enable-threads=posix
2012/5/9 K. Frank :
> Hi Gaby!
>
> On Wed, May 9, 2012 at 3:08 PM, Gabriel Dos Reis
> wrote:
>> On Wed, May 9, 2012 at 2:06 PM, K. Frank wrote:
>>
>>> However, as noted in my previous post, I have happily done some
>>> (limited) windows-api threading programming with Ruben's build
>>> (and also d
On Wed, May 9, 2012 at 2:30 PM, K. Frank wrote:
> Hi Gaby!
>
> On Wed, May 9, 2012 at 3:08 PM, Gabriel Dos Reis
> wrote:
>> On Wed, May 9, 2012 at 2:06 PM, K. Frank wrote:
>>
>>> However, as noted in my previous post, I have happily done some
>>> (limited) windows-api threading programming with
Op 9 mei 2012 21:30 schreef "K. Frank" het volgende:
>
> Hi Gaby!
>
> On Wed, May 9, 2012 at 3:08 PM, Gabriel Dos Reis
> wrote:
> > On Wed, May 9, 2012 at 2:06 PM, K. Frank wrote:
> >
> >> However, as noted in my previous post, I have happily done some
> >> (limited) windows-api threading progra
2012/5/9 Gabriel Dos Reis :
> On Wed, May 9, 2012 at 2:13 PM, Ruben Van Boxem
> wrote:
>
>
>> That said, a new threading model is great, but essentially unusable on
>> Windows XP. Which today might be a problem for people distributing binaries.
>> They'll have to build two versions (as I've said b
On Wed, May 9, 2012 at 2:13 PM, Ruben Van Boxem
wrote:
> That said, a new threading model is great, but essentially unusable on
> Windows XP. Which today might be a problem for people distributing binaries.
> They'll have to build two versions (as I've said before) and confuse their
> users even
Hi Gaby!
On Wed, May 9, 2012 at 3:08 PM, Gabriel Dos Reis
wrote:
> On Wed, May 9, 2012 at 2:06 PM, K. Frank wrote:
>
>> However, as noted in my previous post, I have happily done some
>> (limited) windows-api threading programming with Ruben's build
>> (and also did the windows-api threading pro
Hi Ruben!
On Wed, May 9, 2012 at 3:03 PM, Ruben Van Boxem
wrote:
> 2012/5/9 Jonathan Wakely
>> ...
>> That's not an option. If there is to be a non-backwards-compatible
>> implementation then it must be a new thread model,
>> e.g.--enable-threads=win64 (yes, that name is wrong, it's just an
>>
Forgot to reply to all, my apologies...
2012/5/9 Jonathan Wakely
> On 9 May 2012 16:58, K. Frank wrote:
> > Hello Jonathan!
> >
> > I've taken the liberty of cross-posting this to the mingw list
> > (a separate project from mingw-w64), as they are the other
> > big windows-focused "downstream" c
On Wed, May 9, 2012 at 2:06 PM, K. Frank wrote:
> However, as noted in my previous post, I have happily done some
> (limited) windows-api threading programming with Ruben's build
> (and also did the windows-api threading programming necessary
> to implement ), all, I guess, with a gcc build built
Hi Jonathan!
On Wed, May 9, 2012 at 1:47 PM, Jonathan Wakely wrote:
> On 9 May 2012 16:58, K. Frank wrote:
>> ...
>> One note: In my experimentation, I wrote some windows-api
>> threading programs and built them without specifying
>> --enable-threads=win32, and they all seemed to work., So I
>
2012/5/9 Jonathan Wakely
> On 9 May 2012 16:58, K. Frank wrote:
> > Hello Jonathan!
> >
> > I've taken the liberty of cross-posting this to the mingw list
> > (a separate project from mingw-w64), as they are the other
> > big windows-focused "downstream" consumer of gcc.
> >
> > On Wed, May 9, 20
On 9 May 2012 17:28, Earnie Boyd wrote:
> On Wed, May 9, 2012 at 11:58 AM, K. Frank wrote:
>> Again, I'm not all that big on backward compatibility, and, as noted
>> above, I don't understand what --enable-threads=win32 is for. But
>> my gut reaction is if that the gcc implementation (with
>> -
On 9 May 2012 16:58, K. Frank wrote:
> Hello Jonathan!
>
> I've taken the liberty of cross-posting this to the mingw list
> (a separate project from mingw-w64), as they are the other
> big windows-focused "downstream" consumer of gcc.
>
> On Wed, May 9, 2012 at 9:29 AM, Jonathan Wakely wrote:
>> O
On Wed, May 9, 2012 at 12:04 PM, K. Frank wrote:
>
> Personally, as mentioned above, I am quite happy with the winpthreads
> implementation of , as made available in Ruben's build.
>
> Please, let's have mingw-w64 (and mingw) users chime in. Do folks
> prefer one approach (native vs. pthreads) to
On Wed, May 9, 2012 at 11:58 AM, K. Frank wrote:
> Again, I'm not all that big on backward compatibility, and, as noted
> above, I don't understand what --enable-threads=win32 is for. But
> my gut reaction is if that the gcc implementation (with
> --enable-threads=win32) is sub-optimal, maybe i
On Wed, May 9, 2012 at 11:00 AM, K. Frank wrote:
> Conversely, if you want to mix with pthreads, then a
> pthreads implementation for makes sense.
except that on Windows, programmers don't typically
expect posix functions. If you want posix emulation on Windows,
the general expectation is tha
On Wed, May 9, 2012 at 10:58 AM, K. Frank wrote:
> Ah, okay. I don't use --enable-threads=win32 or really know what
> it is.
It is the default threading model for mingw-64 compilers -- e.g.
gcc built by TDM, etc.
-- Gaby
---
On Wed, May 9, 2012 at 11:04 AM, K. Frank wrote:
> Please, let's have mingw-w64 (and mingw) users chime in. Do folks
> prefer one approach (native vs. pthreads) to implementing
> to the other? Is there enough interest in both approaches that it
> makes sense to take away manpower from other is
Hi Kai!
(Again cross-posted to mingw.)
On Wed, May 9, 2012 at 10:23 AM, Kai Tietz wrote:
> 2012/5/9 Gabriel Dos Reis :
>> On Wed, May 9, 2012 at 8:39 AM, Jonathan Wakely
>> wrote:
>>> On 7 May 2012 18:35, K. Frank wrote:
Hello Ruben and Gabriel!
>>> ...
And my P.S.: As I mentioned i
Hi Jonathan!
(Again, cross-posted to mingw.)
On Wed, May 9, 2012 at 9:39 AM, Jonathan Wakely wrote:
> On 7 May 2012 18:35, K. Frank wrote:
>> Hello Ruben and Gabriel!
>
> N.B. I'm not on the mingw lists, so please keep me CC'd if you want
> responses or any help from me in enhancing libstdc++ to
Hello Jonathan!
I've taken the liberty of cross-posting this to the mingw list
(a separate project from mingw-w64), as they are the other
big windows-focused "downstream" consumer of gcc.
On Wed, May 9, 2012 at 9:29 AM, Jonathan Wakely wrote:
> On 7 May 2012 18:28, K. Frank wrote:
>> Hello Gabri
2012/5/9 Gabriel Dos Reis :
> On Wed, May 9, 2012 at 8:39 AM, Jonathan Wakely wrote:
>> On 7 May 2012 18:35, K. Frank wrote:
>>> Hello Ruben and Gabriel!
>>
>> N.B. I'm not on the mingw lists, so please keep me CC'd if you want
>> responses or any help from me in enhancing libstdc++ to work better
On 7 May 2012 18:28, K. Frank wrote:
> Hello Gabriel (and Ruben)!
>
> By the way, I'm the guy Ruben mentioned in his subsequent post.
>
> On Sat, May 5, 2012 at 11:20 PM, Gabriel Dos Reis
> wrote:
>> Including the mingw64 project about this.
>>
>> On Sat, May 5, 2012 at 5:59 PM, Jonathan Wakely
On 7 May 2012 18:35, K. Frank wrote:
> Hello Ruben and Gabriel!
N.B. I'm not on the mingw lists, so please keep me CC'd if you want
responses or any help from me in enhancing libstdc++ to work better on
Windows.
> And my P.S.: As I mentioned in my earlier post, I have been using Ruben's
> -enab
On Wed, May 9, 2012 at 8:39 AM, Jonathan Wakely wrote:
> On 7 May 2012 18:35, K. Frank wrote:
>> Hello Ruben and Gabriel!
>
> N.B. I'm not on the mingw lists, so please keep me CC'd if you want
> responses or any help from me in enhancing libstdc++ to work better on
> Windows.
>
>
>> And my P.S.:
On Wed, May 9, 2012 at 7:32 PM, Ruben Van Boxem wrote:
>
> I regret to inform you that GCC 4.7.0's libstdc++ suffers the same problem
> and Clang refuses to compile stuff with -std=c++11. I won't be uploading
> the new build cause it adds nothing new at all.
>
>
No worries, thanks for trying. Hope
tch (all I did was hoist the defines out of the #if, which
> >> seemed to work on my end):
> >>
> http://dl.dropbox.com/u/74751/cpp/mingw-w64/patches/mingw-w64-mapvirtualkeyex-fix-20120509-1826.patch
> >>
> >> Index: mingw-w64-headers/include/winuser.h
> >> =
get of Windows 7.
>>
>> The defines seem to have been incorrectly grouped with the Windows 7
>> touch
>> related APIs.
>>
>> Tentative patch (all I did was hoist the defines out of the #if, which
>> seemed to work on my end):
>> http://dl.dropbox.com/u/74
2012/5/8 Joshua Boyce
> On Tue, May 8, 2012 at 7:28 PM, Ruben Van Boxem
> wrote:
>
>> I will see if I can get a GCC 4.7 built, which is said to work with
>> Clang, although they think it might be a Windows only thing, as the headers
>> in question are full of ifdef's. Let's hope 4.7 fixes everyt
een incorrectly grouped with the Windows 7 touch
> related APIs.
>
> Tentative patch (all I did was hoist the defines out of the #if, which
> seemed to work on my end):
> http://dl.dropbox.com/u/74751/cpp/mingw-w64/patches/mingw-w64-mapvirtualkeyex-fix-20120509-1826.patch
>
> Index:
related APIs.
Tentative patch (all I did was hoist the defines out of the #if, which
seemed to work on my end):
http://dl.dropbox.com/u/74751/cpp/mingw-w64/patches/mingw-w64-mapvirtualkeyex-fix-20120509-1826.patch
Index: mingw-w64-headers/include/winuser.h
34 matches
Mail list logo
