22.10.2013, в 8:11, Alexpux написал(а):
>
> 22.10.2013, в 1:11, Óscar Fuentes написал(а):
>
>> Alexey Pavlov writes:
>>
>>> New MSYS2 snapshots:
>>>
>>> 32-bit:
>>> x32-msys2-20131021.tar.xz<http://sourceforge.net/projects
22.10.2013, в 1:11, Óscar Fuentes написал(а):
> Alexey Pavlov writes:
>
>> New MSYS2 snapshots:
>>
>> 32-bit:
>> x32-msys2-20131021.tar.xz<http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-20131021.tar.xz/download>
>>
Alexey Pavlov writes:
> New MSYS2 snapshots:
>
> 32-bit:
> x32-msys2-20131021.tar.xz<http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-20131021.tar.xz/download>
>
> 64-bit:
> x64-msys2-20131021.tar.xz<http://sourceforge.net/projects
"John E. / TDM"
writes:
> With MSYS 1.0, the make job server exposes a race condition in the
> underlying MSYS DLL code that leads to child make processes freezing up
> in many cases when trying to run parallel make jobs with the -j command.
> I've never been able to complete a parallel build
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
sbuild[1] was bumped to 3.2 due to the basic toolchain update - mingw
gcc was updated to 4.8.2 and most of its dependencies were updated as well:
binutils-2.23.90.20131017-1
cloog-0.18.1-1
gcc-4.8.2-1
gmp-5.1.3-1
mingw-w64-crt-svn-r6358-1
mingw-w64-he
On 10/21/2013 1:10 PM, Alexey Pavlov wrote:
> New MSYS2 snapshots:
*snip*
Hi Alexey,
I just wanted to congratulate you on your work and provide another data
point. I've started using MSYS2 to perform GCC toolchain builds and it
appears to perform admirably well.
With MSYS 1.0, the make job ser
New MSYS2 snapshots:
32-bit:
x32-msys2-20131021.tar.xz<http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-20131021.tar.xz/download>
64-bit:
x64-msys2-20131021.tar.xz<http://sourceforge.net/projects/msys2/files/Alpha-versions/64-bit/x64-msys2-201310
2013/10/21 LRN
> W32 semaphores[1] are shared by default.
> mingw-w64 winpthreads use these semaphores internally when pshared is
> PTHREAD_PROCESS_SHARED, so yes, this is supported (judging by the code;
> you will have to test it to see if it actually works).
>
>
Will do the testint. I'll let yo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 21.10.2013 20:32, Edscott Wilson wrote:
> In Linux, you can get a piece of shared memory, put a posix semaphore in
> there, and use it amongst independent processes. This is done by setting
> the second parameter of sem_init() to 1. In FreeBSD this
In Linux, you can get a piece of shared memory, put a posix semaphore in
there, and use it amongst independent processes. This is done by setting
the second parameter of sem_init() to 1. In FreeBSD this functionality is
not supported (at least the last time I looked).
Does anybody on the list know
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 21.10.2013 12:19, Kai Tietz wrote:
> So. the experiment on trunk for the stpcpy implementation didn't worked.
> You gave yourself already the answer. It isn't part of the msvcrt
> C-runtime. There is in general no need to implement it as it is par
asmwarrior 2013-10-20 19:22:
> Please write a note in the site:
> http://sourceforge.net/projects/mingwbuilds/, saying something like:
> the mingw-builds site is not updated any more, the new builds will be
> hold in mingw-w64 site...
> So new users can quickly find the newest builds in
> http://so
So. the experiment on trunk for the stpcpy implementation didn't worked.
You gave yourself already the answer. It isn't part of the msvcrt
C-runtime. There is in general no need to implement it as it is part
of libiberty, It causes troubles on building important stuff like
binutils, gdb, and gcc
13 matches
Mail list logo
