On 7/27/2012 4:03 PM, Kai Tietz wrote:
> 2012/7/27 niXman :
>> 2012/7/27 Kyle Schwarz:
>>> Hi,
>>>
>>> I'm getting a syntax error when trying to compile the latest winpthread.
>>
>> Hmm... This is strange. I've built winpthreads a hour ago.
>>
>>
>> --
>> Regards,
>> niXman
>
> Hmm, no idea. You m
Hi Roger,
2012/7/27 Roger Pack :
>> So, I made spinlocks "fair" by revision 5274. This means that no
>> threads get *lost* on scheduling, if lock is requested.
>>
>> Please give this version a try.
>
> I have tried it, thanks for the patch!
>
> Unfortunately it appears that (ffmpeg + libx264 usin
2012/7/27 K. Frank :
> Hi Kai!
>
> On Fri, Jul 27, 2012 at 4:09 PM, Kai Tietz wrote:
>> So, I made spinlocks "fair" by revision 5274. This means that no
>> threads get *lost* on scheduling, if lock is requested.
>
> This is purely a matter of multi-threading curiosity on my part.
>
> How much add
> So, I made spinlocks "fair" by revision 5274. This means that no
> threads get *lost* on scheduling, if lock is requested.
>
> Please give this version a try.
I have tried it, thanks for the patch!
Unfortunately it appears that (ffmpeg + libx264 using it at least)
appears to deadlock (?) after
Hi Kai!
On Fri, Jul 27, 2012 at 4:09 PM, Kai Tietz wrote:
> So, I made spinlocks "fair" by revision 5274. This means that no
> threads get *lost* on scheduling, if lock is requested.
This is purely a matter of multi-threading curiosity on my part.
How much additional cost (if any) do you think
So, I made spinlocks "fair" by revision 5274. This means that no
threads get *lost* on scheduling, if lock is requested.
Please give this version a try.
Thanks in advance,
Kai
--
Live Security Virtual Conference
Exclusi
2012/7/27 niXman :
> 2012/7/27 Kyle Schwarz:
>> Hi,
>>
>> I'm getting a syntax error when trying to compile the latest winpthread.
>
> Hmm... This is strange. I've built winpthreads a hour ago.
>
>
> --
> Regards,
> niXman
Hmm, no idea. You might have altered something? I don't have this
issue o
2012/7/27 Kyle Schwarz:
> Hi,
>
> I'm getting a syntax error when trying to compile the latest winpthread.
Hmm... This is strange. I've built winpthreads a hour ago.
--
Regards,
niXman
___
Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit
mingw-w64-20120727/mingw-w64-i686/i686-w64-mingw32
The error I got was:
/bin/bash ./libtool --tag=CC --mode=compile i686-w64-mingw32-windres
-i ../../source/mingw-w64-svn/experimental/winpthreads/src/version.rc
-o src/version.lo
libtool: compile: i686-w64-mingw32-windres -i
../../source/ming
On 07/27/12 16:48, Corinna Vinschen wrote:
> On Jul 27 15:10, Corinna Vinschen wrote:
>> On Jul 27 14:47, Kai Tietz wrote:
>>> Hello Corinna,
>>>
>>> The patch is ok. My eyes suffer pain ;)
>> I share your pain. Proof-reading this patch is a PITA. Patch applied.
>> Next week I'll start with the
Hi,
in ndrtypes.h I dropped the UL qualifiers since the values are small
positive, and the C type conversion rules will make these expressions
unsigned long anyway. There's also no good reason to add UL to enum
and typed const values. Hope that's ok.
Thanks,
Corinna
* ndrtypes.h (NDR
On Jul 27 15:10, Corinna Vinschen wrote:
> On Jul 27 14:47, Kai Tietz wrote:
> > Hello Corinna,
> >
> > The patch is ok. My eyes suffer pain ;)
>
> I share your pain. Proof-reading this patch is a PITA. Patch applied.
> Next week I'll start with the __LONG32 stuff.
Not quite. I forgot the un
On Jul 27 14:47, Kai Tietz wrote:
> Hello Corinna,
>
> The patch is ok. My eyes suffer pain ;)
I share your pain. Proof-reading this patch is a PITA. Patch applied.
Next week I'll start with the __LONG32 stuff.
Thanks,
Corinna
On Jul 27 14:49, Ruben Van Boxem wrote:
> 2012/7/27 Corinna Vinschen
>
> > On Jul 27 14:35, Ruben Van Boxem wrote:
> > > I will attempt a combined tree with winsup and newlib and see where I
> > get.
> > > I really hope there's no MinGW.org centric hard-coded directories in the
> > > build.
> >
>
2012/7/27 Corinna Vinschen
> On Jul 27 14:35, Ruben Van Boxem wrote:
> > I will attempt a combined tree with winsup and newlib and see where I
> get.
> > I really hope there's no MinGW.org centric hard-coded directories in the
> > build.
>
> There are! The mingw (Mingw32) and w32api dirs are sub
Hello Corinna,
The patch is ok. My eyes suffer pain ;)
Thanks,
Kai
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers
On Jul 27 14:35, Ruben Van Boxem wrote:
> I will attempt a combined tree with winsup and newlib and see where I get.
> I really hope there's no MinGW.org centric hard-coded directories in the
> build.
There are! The mingw (Mingw32) and w32api dirs are subdirs of winsup,
so you get them "for free"
2012/7/23 Corinna Vinschen
> On Jul 21 13:04, Ruben Van Boxem wrote:
> > Hi,
> >
> > I've seen a lot of chatter/patches going into MinGW-w64 for Cygwin
> support,
> > which is great, as I've noticed a lot of small inconsistencies and code
> > clarity issues are being fixed.
> >
> > What I would l
Patch is ok. Please go ahead.
Thanks,
Kai
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
On Jul 27 12:55, Kai Tietz wrote:
> Hallo Corinna,
> [...]
> Changes in cdosys.h are ok.
>
> In pdh.h I have the following nits:
>
> > +#define IsSuccessSeverity(ErrorCode) DWORD)(ErrorCode) &
> > (0xC000))==(DWORD)0x) ? TRUE : FALSE)
> Here please replace the 'X == (DWORD) 0x0'
Hallo Corinna,
2012/7/26 Corinna Vinschen :
> Hi,
>
> more avoidance of __MSABI_LONG below.
>
> Here's a question. I already had a look into the end result after
> applying the bulk __MSABI_LONG patch. Apart from the fact that it
> affects a 5 digit number of lines, it looks... ugly. The string
On Jul 27, 2012, at 9:10 AM, niXman wrote:
> 2012/7/27 NightStrike:
>>
>> You might want to check out gcc 4.7.2 with current trunk mingw-w64
>> crt/headers. I believe SEH is in as of the 4th of July.
>
> Are you saying that this code will be execute correctly?
>
> try {
> int* i = 0;
> co
Patch is ok.
Thanks,
Kai
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpo
Hi,
I forgot to add intrin.h to the required headers in a PSDK-only install.
It's included by winnt.h. Patch below.
Thanks,
Corinna
* configure.ac (BASEHEAD_LIST): Add crt/intrin.h
* configure: Regenerate.
Index: configure
2012/7/27 NightStrike:
>
> You might want to check out gcc 4.7.2 with current trunk mingw-w64
> crt/headers. I believe SEH is in as of the 4th of July.
Are you saying that this code will be execute correctly?
try {
int* i = 0;
cout << *i << endl;
} catch ( ... ) {
cout << "exception" <<
25 matches
Mail list logo
