On 2013-12-05 22:48, wynfield wrote:
> I understand that on cygwin /bin and /usr/bin both point to the same
> directory.
Correct.
> Given that and that the ming2-w64 gcc program is shown to be the exact same
> length and have the same md5sums, I assumed that they were all equal.
>
> -rwxr-xr-x
06 дек. 2013 г., в 8:48, wynfi...@gmail.com написал(а):
>
> I understand that on cygwin /bin and /usr/bin both point to the same
> directory.
No. On cygwin this is two different directories.
They are the same on MSYS.
Regards,
Alexey.
> Given that and that the ming2-w64 gcc program is shown
I understand that on cygwin /bin and /usr/bin both point to the same directory.
Given that and that the ming2-w64 gcc program is shown to be the exact same
length and have the same md5sums, I assumed that they were all equal.
-rwxr-xr-x 2 692765 Dec 1 /bin/i686-w64-mingw32-gcc
-rwxr-xr-x 2
A few thoughts:
1) Shouldn't global_lock be __LONG32?
2) Would it make sense for the exchange on global_lock to be done as a
single operation (ie InterlockedCompareExchange)?
dw
On 12/5/2013 10:45 AM, Fanael Linithien wrote:
I came up with a patch that fixes the issue for me.
The patch repl
2013/12/5 Fanael Linithien :
> I came up with a patch that fixes the issue for me.
>
> The patch replaces the global critical section with a spinlock.
> Critical sections require explicit initialization before use, which in
> this case is not possible: register_frame_ctor (from libgcc), which
> run
I came up with a patch that fixes the issue for me.
The patch replaces the global critical section with a spinlock.
Critical sections require explicit initialization before use, which in
this case is not possible: register_frame_ctor (from libgcc), which
runs BEFORE enter_global_cs, tries to lock
Hi,
following patch makes sure that DECLSPEC_DEPRECATED isn't defined to
declspec for widl-mode. Also it undefines DEPRECATE_SUPPORTED macro
in widl-mode.
Ok for apply?
Kai
Index: winnt.h
===
--- winnt.h (Revision 6390)
+++ wi
I believe it is possible, but you have to explicitly tell it with the gcc
option -municode.
Martin
> I am not sure what is the status now, but couple of years ago, GCC could
> not compile programs with UNICODE version of WinMain. If it still
> persist, you will need to declare the entry point as
2013/12/5 Pavel
> I am not sure what is the status now, but couple of years ago, GCC could
> not compile programs with UNICODE version of WinMain. If it still
> persist, you will need to declare the entry point as
>
> int main(int argc, char **argv)
>
> You can get the UNICODE command line argume
I am not sure what is the status now, but couple of years ago, GCC could
not compile programs with UNICODE version of WinMain. If it still
persist, you will need to declare the entry point as
int main(int argc, char **argv)
You can get the UNICODE command line arguments later by calling
GetComman
>From: JonY
>Date: Thu, 05 Dec 2013 17:23:48 +0800
>Subject: Re: [Mingw-w64-public] Using MinGW-w64
>On 12/5/2013 12:58, wynfield wrote:
>> # I then tried to compile it, but it failed as soon below.
>>
>> $ /bin/i686-w64-mingw32-gcc.exe hello.c
>>i686-w64-mingw32-gcc: error: spawn:
Hi,
thanks for the review.
2013/12/4 JonY :
> On 12/5/2013 04:17, Kai Tietz wrote:
>> Hi,
>>
>> could somebody of you please review http://pastebin.com/w91sSRk0
>>
>> Thanks,
>> Kai
>>
>
> Is this correct? CONST to const
>
> -POINT CONST *pptDst;
> -SIZE CONST *psize;
> +const POINT *
On 12/5/2013 12:58, wynfield wrote:
> # I then tried to compile it, but it failed as soon below.
>
> $ /bin/i686-w64-mingw32-gcc.exe hello.c
>i686-w64-mingw32-gcc: error: spawn: No such file or directory
>
>
Don't do that, just use i686-w64-mingw32-gcc, or
/usr/bin/i686-w64-mingw3
13 matches
Mail list logo
