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" <<
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
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
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
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 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'
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
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
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"
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
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
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.
> >
>
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 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
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 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
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
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
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
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
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.
I have tried it, thanks for the patch!
Unfortunately it appears that (ffmpeg + libx264 using it at least)
appears to deadlock (?) after
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
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
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
25 matches
Mail list logo
