在 2025-6-22 03:15, Kirill Makurin 写道:
This should fix error when compiling C++ modules[1].
- Kirill Makurin
[1] https://github.com/mingw-w64/mingw-w64/issues/99
Thanks for the patch. Pushed now.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
This should fix error when compiling C++ modules[1].
- Kirill Makurin
[1] https://github.com/mingw-w64/mingw-w64/issues/99
From c3d9c047a80ee40545388a0359f25fa3d1f4a95e Mon Sep 17 00:00:00 2001
From: Kirill Makurin
Date: Sun, 22 Jun 2025 04:01:04 +0900
Subject: [PATCH] winpthreads: fix compiling
ll Makurin
From: LIU Hao
Sent: Wednesday, June 11, 2025 11:58 PM
To: mingw-w64-public@lists.sourceforge.net; Kirill Makurin
Subject: Re: [Mingw-w64-public] winpthreads: do not expose IN_WINPTHREAD in
public header files
在 2025-6-6 17:41, Kirill Makurin
From: LIU Hao
Sent: Wednesday, June 11, 2025 11:58 PM
To: mingw-w64-public@lists.sourceforge.net; Kirill Makurin
Subject: Re: [Mingw-w64-public] winpthreads: do not expose IN_WINPTHREAD in
public header files
在 2025-6-6 17:41, Kirill Makurin 写道:
> From 8c131c07c784799b56a889b0c25396e0c0ddb9e
在 2025-6-6 17:41, Kirill Makurin 写道:
From 8c131c07c784799b56a889b0c25396e0c0ddb9e8 Mon Sep 17 00:00:00 2001
From: Kirill Makurin
Date: Fri, 6 Jun 2025 18:26:24 +0900
Subject: [PATCH] winpthreads: do not expose IN_WINPTHREAD in public header
files
When building winpthreads, define WINPTHREAD_AP
See commit message.
I have a question. What do you think about adding .pc (pkg-config) file for
winpthreads?
There is also a problematic interaction between pthread_compat.h and autoconf's
AC_TYPE_PID_T. With MSVC, this check will fail and it will
```
#define pid_t ...
```
If pthread_compat.h
在 2025-6-3 23:46, Kirill Makurin 写道:
You are right. `libtool --mode=execute` is no longer needed.
I forgot that libtool creates wrapper executables which handle search path.
I attached update patch.
Thanks for the patch. Looks good to me. Pushed now.
--
Best regards,
LIU Hao
OpenPGP_sig
-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] winpthreads: make testing shared library work
在 2025-6-3 17:44, Kirill Makurin 写道:
> This is a good idea. Plain `LDADD` (not `LIBADD`) is used to add libraries to
> all programs in current
> Makefile.am.
Oh thank you. I keep f
在 2025-6-3 17:44, Kirill Makurin 写道:
This is a good idea. Plain `LDADD` (not `LIBADD`) is used to add libraries to all programs in current
Makefile.am.
Oh thank you. I keep forgetting that.
From 2347a4099e1340a2789ac9f11001c25548463e69 Mon Sep 17 00:00:00 2001
From: Kirill Makurin
Date: Tue
; Kirill Makurin
Subject: Re: [Mingw-w64-public] winpthreads: make testing shared library work
在 2025-6-1 15:06, Kirill Makurin 写道:
> diff --git a/mingw-w64-libraries/winpthreads/tests/Makefile.am
> b/mingw-w64-libraries/winpthreads/tests/Makefile.am
> index 9dda82f73..74549952d 100644
>
在 2025-6-1 15:06, Kirill Makurin 写道:
diff --git a/mingw-w64-libraries/winpthreads/tests/Makefile.am
b/mingw-w64-libraries/winpthreads/tests/Makefile.am
index 9dda82f73..74549952d 100644
--- a/mingw-w64-libraries/winpthreads/tests/Makefile.am
+++ b/mingw-w64-libraries/winpthreads/tests/Makefile.a
See commit message.
- Kirill Makurin
From a0a35f2d0eefed69c2d789eb50fb222b9566768a Mon Sep 17 00:00:00 2001
From: Kirill Makurin
Date: Sun, 1 Jun 2025 15:54:23 +0900
Subject: [PATCH] winpthreads: make testing shared library work
Running `make check` when configured with `--disable-static`,
depen
在 2025-4-20 01:28, Kirill Makurin 写道:
Please let me know if patches in 0005.txt and 0006.txt are ok. I would like to reorder them before large
changes.
Those look good to me.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
: [Mingw-w64-public] winpthreads: add support for _USE_32BIT_TIME_T
and _TIME_BITS macros
在 2025-4-19 21:45, Kirill Makurin 写道:
> `SIZEOF_TIME_T` is defined in config.h as the result of
> `AC_CHECK_SIZEOF(time_t)` added to configure.ac.
> (I did not included result from running `autorecon
uld expect unsuffixed versions to use time_t of the
corresponding size.
- Kirill Makurin
From: LIU Hao
Sent: Saturday, April 19, 2025 11:05 PM
To: Kirill Makurin; mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] winpthreads: add s
在 2025-4-19 21:45, Kirill Makurin 写道:
`SIZEOF_TIME_T` is defined in config.h as the result of `AC_CHECK_SIZEOF(time_t)` added to configure.ac.
(I did not included result from running `autoreconf` in the patches).
Thanks for noticing usage of `inline`, I think it also makes sense for existing
`
`errno` to `ERANGE` in clock_gettime32 if
time does not fit in 32bit time_t. Is there any better `errno` value for this?
- Kirill Makurin
From: LIU Hao
Sent: Saturday, April 19, 2025 8:35 PM
To: mingw-w64-public@lists.sourceforge.net; Kirill Makurin
Subject: Re: [Mingw-
在 2025-4-15 10:22, Kirill Makurin 写道:
--- a/mingw-w64-libraries/winpthreads/include/pthread_compat.h
+++ b/mingw-w64-libraries/winpthreads/include/pthread_compat.h
@@ -98,6 +98,7 @@ typedef unsigned short mode_t;
#ifdef __GNUC__
#define WINPTHREADS_INLINE inline
+#define WINPTHREADS_ALWAY
Hi,
There have been discussions about adding support for _FILE_BITS and _TIME_BITS
macros in mingw-w64 header files.
Some of functions provided by winpthreads library use `struct timespec` which
depends on `time_t`, however winpthreads does not handle _USE_32BIT_TIME_t and
_TIME_BITS macros.
在 2025-02-26 20:12, Kirill Makurin 写道:
Thanks for letting me know. I was afraid something like this could happen since pthread_signal.h is
included from mingw-w64's signal.h.
Still, I think we could include pthread_signal.h from pthread.h for MSVC compilation. Maybe also
move `SIG_*` macros cl
在 2025-02-26 09:24, LIU Hao 写道:
在 2025-02-20 01:38, Kirill Makurin 写道:
From: Kirill Makurin
Sent: Thursday, February 20, 2025 2:33 AM
To: mingw-w64-public
Subject: winpthreads: a few more header file cleanups
Patch 1: remove old, commented out typedef for `pthread_t`.
Patch 2: move `SIG_BLOC
在 2025-02-20 01:38, Kirill Makurin 写道:
From: Kirill Makurin
Sent: Thursday, February 20, 2025 2:33 AM
To: mingw-w64-public
Subject: winpthreads: a few more header file cleanups
Patch 1: remove old, commented out typedef for `pthread_t`.
Patch 2: move `SIG_BLOCK`, `SIG_UNBLOCK` and `SIG_SETMAS
Sorry, I forgot to attach patches.
From: Kirill Makurin
Sent: Thursday, February 20, 2025 2:33 AM
To: mingw-w64-public
Subject: winpthreads: a few more header file cleanups
Patch 1: remove old, commented out typedef for `pthread_t`.
Patch 2: move `SIG_BLOCK`, `S
Patch 1: remove old, commented out typedef for `pthread_t`.
Patch 2: move `SIG_BLOCK`, `SIG_UNBLOCK` and `SIG_SETMASK` from pthread.h to
pthread_signal.h. Also include pthread_signal.h from pthread.h when compiling
with MSVC.
Please note that pthread_signal.h is also included from mingw-w64's s
在 2025-02-16 21:46, Kirill Makurin 写道:
The `pthread.h`, `pthread_time.h` and `sched.h` include `sys/timeb.h`. The
`ftime` function was marked obsolete and later removed in POSIX 2008.
I don't see any reason to include this header file unless some legacy projects
rely on `ftime` being available
The `pthread.h`, `pthread_time.h` and `sched.h` include `sys/timeb.h`. The
`ftime` function was marked obsolete and later removed in POSIX 2008.
I don't see any reason to include this header file unless some legacy projects
rely on `ftime` being available when including `pthread.h`, which seems
在 2025-02-10 16:41, Kirill Makurin 写道:
We already moved `WINPTHREAD_API` and `clockid_t` to pthread_compat.h. Also
move `mode_t` (from sched.h) to and errno constants (from pthread.h) to
pthread_compat.h.
sched.h and semaphore.h use `WINPTHREAD_SCHED_API` and `WINPTHREAD_SEMA_API`
instead of
We already moved `WINPTHREAD_API` and `clockid_t` to pthread_compat.h. Also
move `mode_t` (from sched.h) to and errno constants (from pthread.h) to
pthread_compat.h.
sched.h and semaphore.h use `WINPTHREAD_SCHED_API` and `WINPTHREAD_SEMA_API`
instead of `WINPTHREAD_API`. Include pthread_compat.
在 2025-01-31 15:31, LIU Hao 写道:
在 2025-01-31 15:02, Kirill Makurin 写道:
I think `"pthread_time.h"` makes more sense when including headers from the
source tree?
Hmm, that's true in general. I think the updated patch is acceptable.
I have pushed patch1 and t_nanosleep now.
--
Best regards,
在 2025-01-31 15:02, Kirill Makurin 写道:
I think `"pthread_time.h"` makes more sense when including headers from the
source tree?
Hmm, that's true in general. I think the updated patch is acceptable.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
__
public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] winpthreads and MSVC
On 1/30/25 3:02 AM, Kirill Makurin wrote:
> Yes, no problem.
>
> I also had a patch for Makefile.am which tried to solve the alias issue by
> copying `[lib]winpthreads[.dll].{lib|a}` as `[lib]pthread[.dll].
I think `"pthread_time.h"` makes more sense when including headers from the
source tree?
From: LIU Hao
Sent: Friday, January 31, 2025 3:57 PM
To: Kirill Makurin; mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] winpthreads and MS
在 2025-01-31 14:48, Kirill Makurin 写道:
I assume `getntptimeofday` is provided by mingw-w64 runtime. Maybe author of the test did not want
to use winpthreads' `clock_gettime` for the test?
Anyway, I attached a patch which replaces calls to `getntptimeofday` with calls to `clock_gettime`.
I thin
using `clock_gettime` is that
if it somehow breaks, it will also make this test to fail.
From: LIU Hao
Sent: Friday, January 31, 2025 3:07 PM
To: mingw-w64-public@lists.sourceforge.net; Jonathan Yong; Kirill Makurin
Subject: Re: [Mingw-w64-public] winpthreads and MSVC
在 2025-
在 2025-01-30 19:20, Jonathan Yong 写道:
The 2 patches look OK to me, I'll wait for feed back from the others.
The second patch introduces a private implementation of `getntptimeofday()` that does not write
anything into `*tz`. Although all calls to this function in that file pass null pointers f
On 1/30/25 3:02 AM, Kirill Makurin wrote:
Yes, no problem.
I also had a patch for Makefile.am which tried to solve the alias issue by
copying `[lib]winpthreads[.dll].{lib|a}` as `[lib]pthread[.dll].{lib|a}` during
installation. I can send it again.
I see. I could maintain a GitHub repository
and possibly CMake build systems. I think this could be useful.
From: Jonathan Yong <10wa...@gmail.com>
Sent: Thursday, January 30, 2025 10:38 AM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] winpthreads and MSVC
On 1/29/25 9
On 1/29/25 9:58 PM, Kirill Makurin wrote:
Hi,
I was writing to the list a few months ago regarding building of winpthreads
with MSVC tools. I also sent a few patches back then, none of which were
pushed. The first two patches were fixing a syntax error in `src/thread.h` and
linking of `tests/
Hi,
I was writing to the list a few months ago regarding building of winpthreads
with MSVC tools. I also sent a few patches back then, none of which were
pushed. The first two patches were fixing a syntax error in `src/thread.h` and
linking of `tests/t_nanosleep.c`. Other patches tried to fix i
在 2022-05-02 20:25, Martin Storsjö 写道:
On Mon, 2 May 2022, LIU Hao wrote:
--
LGTM, thanks!
Thanks. Amended and pushed to master.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
___
Mingw-w64-public mailing l
在 2022-05-02 20:20, LIU Hao 写道:
+# if defined(WINPTHREADS_USE_DLLIMPORT)
+#define WINPTHREAD_API __declspec(dllimport) /* user wants explicit
`dllimport` */
# else
-#define WINPTHREAD_API __declspec(dllimport)
-# endif
+#define WINPTHREAD_API /* the default; auto imported in
On Mon, 2 May 2022, LIU Hao wrote:
--
LGTM, thanks!
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Best regards,
LIU Hao
From b3d95248f2f8bf2e5863671dbc00ff8dcf2b8aac Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Mon, 2 May 2022 19:53:55 +0800
Subject: [PATCH] winpthreads: Do not use `dllimport` when building 3rd-party
DLLs (V4)
Existent code that is linked against the winpthreads static
On 05/04/2017 01:13 AM, Liu Hao wrote:
> On 2017/5/4 13:54, Daniel Santos wrote:
>> I see one in libgcc, but I guess you would have to add that to your
>> link. I presume it's in the dynamic portion.
> As Kai said yesterday on IRC, in the case of cross compiling libpthread
> has to be available pr
On 2017/5/4 13:54, Daniel Santos wrote:
> I see one in libgcc, but I guess you would have to add that to your
> link. I presume it's in the dynamic portion.
As Kai said yesterday on IRC, in the case of cross compiling libpthread
has to be available prior to libgcc. That is the reason why we link
On 05/03/2017 10:17 AM, Liu Hao wrote:
> On 2017/5/3 18:56, Christer Solskogen wrote:
>> On 03.05.2017 10.23, Liu Hao wrote:
>>> On 2017/5/3 15:35, Christer Solskogen wrote:
I'm having a hard time (cross) compiling winpthreads (from 5.x branch)
with gcc 7.1.
>>> Please try the attached pa
On 2017/5/3 18:56, Christer Solskogen wrote:
> On 03.05.2017 10.23, Liu Hao wrote:
>> On 2017/5/3 15:35, Christer Solskogen wrote:
>>> I'm having a hard time (cross) compiling winpthreads (from 5.x branch)
>>> with gcc 7.1.
>> Please try the attached patch.
>>
>
> Works! Thanks! \o/
>
This is nothi
On 03.05.2017 10.23, Liu Hao wrote:
> On 2017/5/3 15:35, Christer Solskogen wrote:
>> I'm having a hard time (cross) compiling winpthreads (from 5.x branch)
>> with gcc 7.1.
> Please try the attached patch.
>
Works! Thanks! \o/
--
chs
--
On 2017/5/3 15:35, Christer Solskogen wrote:
I'm having a hard time (cross) compiling winpthreads (from 5.x branch)
with gcc 7.1.
Please try the attached patch.
--
Best regards,
LH_Mouse
From 4fa48b2af092a3b8615cef39b6e0036e20481c3f Mon Sep 17 00:00:00 2001
From: Liu Hao
Date: Wed, 3 May 20
I'm having a hard time (cross) compiling winpthreads (from 5.x branch)
with gcc 7.1.
make[2]: Entering directory
'/tmp/obj/_build/winpthreads.cross.i686-w64-mingw32'
/bin/bash ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -Wall
-DWIN32_LEAN_AND_MEAN -O2 -pipe -no-undefined -version-inf
g!
> 发件人："Burkhardt, Glenn B UTAS"
> ...
> 主题：[Mingw-w64-public] winpthreads, pthread_setschedparam,
> and detached threads
>
> The way the winpthreads code is writing, the Windows handle for the thread is
> cleared when the thread is made detached. T
enn BUTAS"
发送日期：2016-06-01 21:25
收件人：mingw-w64-public@lists.sourceforge.net
抄送：
主题：Re: [Mingw-w64-public] winpthreads, pthread_setschedparam,
and detached threads
It's not clear to me from this explanation why this code should fail:
pthread_setschedparam(pthread_self(),
It's not clear to me from this explanation why this code should fail:
pthread_setschedparam(pthread_self(), SCHED_OTHER, ¶m);
but in winpthreads, for a detached thread, it will.
> Re: [Mingw-w64-public] winpthreads, pthread_setschedparam, and detached
> threads
>
.
--
Best regards,
lh_mouse
2016-06-01
-
发件人："Burkhardt, Glenn BUTAS"
发送日期：2016-05-31 23:11
收件人：mingw-w64-public@lists.sourceforge.net
抄送：
主题：[Mingw-w64-public] winpthreads, pthread_set
Hi Glenn!
On Tue, May 31, 2016 at 11:11 AM, Burkhardt, Glenn BUTAS
wrote:
> The way the winpthreads code is writing, the Windows handle for the thread is
> cleared when the thread is made detached. That means that the
> pthread_setschedparam() call can't work. So thread priorities for
The way the winpthreads code is writing, the Windows handle for the thread is
cleared when the thread is made detached. That means that the
pthread_setschedparam() call can't work. So thread priorities for detached
threads can only be set once, at thread creation, before the thread is
detache
Hi,
Consider such code:
*
{
pthread_spinlock_t* lock_pointer;
pthread_spinlock_t lock_value;
lock_pointer = (pthread_spinlock_t*)calloc( 1,
sizeof(pthread_spinlock_t) );
pthread_spin_init( lock_pointer, 0 );
lock_value = *lock_pointer; /* == -1 */
free( lock_pointer );
**
Hi,
Have the executables using the winpthread library been rebuilt?
--
Adrien Nader
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.s
> For debugging issue can be used OpmeMP test
> https://github.com/niXman/mingw-builds/blob/master/tests/omp_test.c
>
> Build it with «gcc omp_test.c -fopenmp -o omp_test.exe» and run.
No crash when I run that code. Is this the same for everybody else?
Perhaps you could find a different test case
> 28 июля 2015 г., в 7:09, Alexey Pavlov написал(а):
>
> Hi, guys!
>
> Our users (MSYS2) report lot of crashes in different applications. We found
> that that crash are happen after upgrading winpthreads and caused one or both
> of two commits:
> Rewrite the pthread spin lock implementation -
Hi, guys!
Our users (MSYS2) report lot of crashes in different applications. We found
that that crash are happen after upgrading winpthreads and caused one or both
of two commits:
Rewrite the pthread spin lock implementation -
https://github.com/msys2/mingw-w64/commit/249898d9ae310959116efa333e
Hi Mattias!
On Sat, Jun 20, 2015 at 4:32 AM, Mattias Engdegård wrote:
> 19 jun 2015 kl. 23.12 skrev Alexandre Pereira Nunes
> :
>
>> I came across this: https://sourceforge.net/p/mingw-w64/bugs/344/
>>
>> Does anyone knows if that's still the case?
>
> Yes. There is a patch, but it has not been
19 jun 2015 kl. 23.12 skrev Alexandre Pereira Nunes :
> I came across this: https://sourceforge.net/p/mingw-w64/bugs/344/
>
> Does anyone knows if that's still the case?
Yes. There is a patch, but it has not been cleared for release yet. It may take
a few weeks more, given that people are on ho
I came across this: https://sourceforge.net/p/mingw-w64/bugs/344/
Does anyone knows if that's still the case?
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourcefo
ds-win32 uses __try/__finally (for SEH) or
pthread_setspecific()/pthread_getspecific() (for C cleanup) to ensure
they're always called.
> - Original Message -
> From: "Keri Harris"
> To:
> Sent: Thursday, March 19, 2015 3:27 PM
> Subject: [Mingw-w6
May be it has some relation with?
http://sourceforge.net/p/mingw-w64/mailman/message/31749147/
- Original Message -
From: "Keri Harris"
To:
Sent: Thursday, March 19, 2015 3:27 PM
Subject: [Mingw-w64-public] winpthreads cleanup handlers not called
afterpthread_exit()
>
I've noticed some unexpected behaviour with winpthreads which I believe
is a bug. Thread-cancellation cleanup handlers are not called when a
thread terminates due to a call to pthread_exit(). This is unexpected;
the pthread_cleanup_push(), pthread_cleanup_pop() specification [1]
mentions:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This was first observed in winpthreads from trunk r6478.
ktietz claimed to have found some problems with mutex destruction, and
committed r6481, then r6482.
After hours of running glimagesink and digging highly verbose log
output, i came to a conclusi
On 12/12/2013 02:32, Kai Tietz wrote:
> Sorry for the delay. Patch is ok. Does somebody would apply it to
> trunk (and if JonY doesn't object also to v3-branch)?
>
> Thanks,
> Kai
>
Done, trunk r6411 and stable/v3.x r6412.
signature.asc
Description: OpenPGP digital signature
-
Sorry for the delay. Patch is ok. Does somebody would apply it to
trunk (and if JonY doesn't object also to v3-branch)?
Thanks,
Kai
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizatio
ping?
2013/12/8 Fanael Linithien :
> Ping?
>
> --
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/cl
ictor Bombi"
> To:
> Sent: Thursday, November 28, 2013 3:04 PM
> Subject: Re: [Mingw-w64-public] winpthreads kill
>
>
>> I dont know how to build. I always use CMake to create makefiles without
>> mysys.
>> Do I need mysys? where do I get configure?
>&
"
To:
Sent: Thursday, November 28, 2013 3:04 PM
Subject: Re: [Mingw-w64-public] winpthreads kill
>I dont know how to build. I always use CMake to create makefiles without
> mysys.
> Do I need mysys? where do I get configure?
>
> - Original Message -
> From: &quo
Ping?
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
2013/12/5 Fanael Linithien :
> runs BEFORE enter_global_cs
Er, before global_spin_ctor, of course.
2013/12/5 Kai Tietz :
> Nice catch. This describes at least the runtime-failure we got reported.
> Did you tested regressions for this patch?
I have. All tests from tests_pthread pass.
2013/12/5
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
Alexey Pavlov 2013-11-28 11:35:
> Hi, all!
>
> I'm have issue with winpthreads from trunk rev.6367 and later. It
> break for me dwarf toolchains with threads=posix. Most generated
> binaries with this toolchain crash on startup.
> For example, I build sqlite3 and winpthreads rev.6367 with debuginf
I dont know how to build. I always use CMake to create makefiles without
mysys.
Do I need mysys? where do I get configure?
- Original Message -
From: "JonY"
To:
Sent: Wednesday, November 27, 2013 11:10 PM
Subject: Re: [Mingw-w64-public] winpth
Hi, all!
I'm have issue with winpthreads from trunk rev.6367 and later. It
break for me dwarf toolchains with threads=posix. Most generated
binaries with this toolchain crash on startup.
For example, I build sqlite3 and winpthreads rev.6367 with debuginfo
and has next GDB backtrace http://pastebin
On 11/28/2013 04:33, Ruben Van Boxem wrote:
> 2013/11/27 Jon
>
>>
>>
>>>
>>> Also: Where should I get the sources for winpthreads?
>>>
>>>
>>
>> http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-libraries/winpthreads/
>>
>
> winpthreads had an official release with 3.0.0. No need
2013/11/27 Jon
>
>
>>
>> Also: Where should I get the sources for winpthreads?
>>
>>
>
> http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-libraries/winpthreads/
>
winpthreads had an official release with 3.0.0. No need for development
versions anymore.
Ruben
>
>
> ---
>
> Also: Where should I get the sources for winpthreads?
>
>
http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-libraries/winpthreads/
--
Rapidly troubleshoot problems before they affect your business. Most
Hello
I am setting pthread_setcanceltype( PTHREAD_CANCEL_ASYNCHRONOUS, NULL); in a
thread in order to kill but it does not work
althought in win32 we could use TerminateThread. Any thoughts?
Also: Where should I get the sources for winpthreads?
Best
victor
On Sun, Apr 14, 2013 at 9:09 AM, LRN wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 14.04.2013 10:54, LRN wrote:
>> This patch should integrate the testsuite imported from pthreads
>> with winpthreads. (includes re-generated configure and Makefile.in
>> - it is very sad that those
have a cpu monitor, and taskmgr.exe can
you can add a column for numthreads per process.
>
> From: LRN
>To: mingw-w64-public@lists.sourceforge.net
>Sent: Sunday, April 14, 2013 9:48 AM
>Subject: Re: [Mingw-w64-public] winpthreads testsuite
May be related to openmp hang that I have reported earlier on this list. I
can repost the example if needed.
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14.04.2013 20:25, K. Frank wrote:
> Hi LRN!
>
> On Sun, Apr 14, 2013 at 10:16 AM, LRN <> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 14.04.2013 17:55, K. Frank wrote:
>>> Hello LRN!
>>>
>>> On Sun, Apr 14, 2013 at 2:54 AM, LR
Hi LRN!
On Sun, Apr 14, 2013 at 10:16 AM, LRN <> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 14.04.2013 17:55, K. Frank wrote:
>> Hello LRN!
>>
>> On Sun, Apr 14, 2013 at 2:54 AM, LRN <...> wrote:
>>> ... This patch should integrate the testsuite imported from
>>> pthreads with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14.04.2013 17:55, K. Frank wrote:
> Hello LRN!
>
> On Sun, Apr 14, 2013 at 2:54 AM, LRN <...> wrote:
>> ... This patch should integrate the testsuite imported from
>> pthreads with winpthreads. ...
>
> Did you ever learn more about / sort out the
Hello LRN!
On Sun, Apr 14, 2013 at 2:54 AM, LRN <...> wrote:
> ...
> This patch should integrate the testsuite imported from pthreads with
> winpthreads.
> ...
Did you ever learn more about / sort out the create / join race
condition you reported earlier?
(Sorry to semi-hijack the current threa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14.04.2013 10:54, LRN wrote:
> This patch should integrate the testsuite imported from pthreads
> with winpthreads. (includes re-generated configure and Makefile.in
> - it is very sad that those are tracked in SVN).
>
OK, here is a better patch -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This patch should integrate the testsuite imported from pthreads with
winpthreads.
(includes re-generated configure and Makefile.in - it is very sad that
those are tracked in SVN).
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment:
2012/7/18 Ozkan Sezer:
> Some very small C program showing the brokenness without
> the change, and showing the healthiness with the change applied.
> The existing tests in winpthreads are examples.
>
Test for patch for pthread_getspecific().
Without the patch, main() return -2.
#include
struct
On Wed, Jul 18, 2012 at 2:02 PM, niXman wrote:
> 2012/7/18 Kai Tietz:
>>
>> I applied the patch at rev 5235. But I still wait for the testcase.
>
> What do you mean by the word "testcase"?
> In the previous message I put a logfile with winpthreads test.
>
Some very small C program showing the br
2012/7/18 Kai Tietz:
>
> I applied the patch at rev 5235. But I still wait for the testcase.
What do you mean by the word "testcase"?
In the previous message I put a logfile with winpthreads test.
--
Regards,
niXman
___
Dual-target(32 & 64 bit) M
2012/7/18 niXman :
> 2012/7/17 niXman:
>> 2012/7/16 Kai Tietz:
>>>
>>> So patch is ok with a testcase.
>>
>> Log in attachment.
>
> ping?
I applied the patch at rev 5235. But I still wait for the testcase.
Cheers,
Kai
-
2012/7/17 niXman:
> 2012/7/16 Kai Tietz:
>>
>> So patch is ok with a testcase.
>
> Log in attachment.
ping?
--
Regards,
niXman
___
Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows:
http://sourceforge.net/projects/mingwbuilds/
--
2012/7/16 Kai Tietz:
> Well,
>
> I am fine by this patch, but I would love to get additional a testcase
> added for it.
>
> So patch is ok with a testcase.
Log in attachment.
--
Regards,
niXman
___
Dual-target(32 & 64 bit) MinGW compilers for 32
1 - 100 of 166 matches
Mail list logo
