Re: [Mingw-w64-public] winpthreads: Do not use `dllimport` when building 3rd-party DLLs (V4)

[LIU Hao]

在 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 list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads: Do not use `dllimport` when building 3rd-party DLLs (V4)

[LIU Hao]

在 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 case of DLL  */


Forgot an #endif here, and in the other two places.


--
Best regards,
LIU Hao


OpenPGP_signature
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads: Do not use `dllimport` when building 3rd-party DLLs (V4)

[Martin Storsjö]

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

[Mingw-w64-public] winpthreads: Do not use `dllimport` when building 3rd-party DLLs (V4)

[LIU Hao]

--
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 library has
not been aware of `WINPTHREAD_STATIC` and attempts to import those
functions, such as libstdc++. Eventually we decide to do the opposite
to 2bf18054ca5206e1a64f2305a5ba07ab2661dd43. All winpthreads APIs are
now undecorated by default, unless `WINPTHREADS_USE_DLLIMPORT` is
defined which makes them `dllimport`. GCC is able to import functions
even without `dllimport` attributes.

Signed-off-by: LIU Hao 
---
 mingw-w64-libraries/winpthreads/README| 10 +-
 mingw-w64-libraries/winpthreads/include/pthread.h | 15 +++
 mingw-w64-libraries/winpthreads/include/sched.h   | 13 ++---
 .../winpthreads/include/semaphore.h   | 13 ++---
 4 files changed, 24 insertions(+), 27 deletions(-)

diff --git a/mingw-w64-libraries/winpthreads/README 
b/mingw-w64-libraries/winpthreads/README
index 50d8dbe9b..55922f00f 100644
--- a/mingw-w64-libraries/winpthreads/README
+++ b/mingw-w64-libraries/winpthreads/README
@@ -3,8 +3,8 @@ The Winpthreads Library
 
 This library provides POSIX threading APIs for mingw-w64.
 
-Programs are usually linked against the winpthreads DLL, and winpthreads
-headers expose `dllimport` APIs by default. When linking against the
-static library, especially when building a user DLL with libtool, it is
-necessary to define the `WINPTHREAD_STATIC` macro to avoid undefined
-references.
+For maximum compatibility, winpthreads headers expose APIs without the
+`dllimport` attribute by default. If your program is linked against the
+DLL, you may define the `WINPTHREADS_USE_DLLIMPORT` macro to add the
+`dllimport` attribute to all APIs, which makes function calls to them a
+bit more efficient.
diff --git a/mingw-w64-libraries/winpthreads/include/pthread.h 
b/mingw-w64-libraries/winpthreads/include/pthread.h
index d17df3352..732e11a10 100644
--- a/mingw-w64-libraries/winpthreads/include/pthread.h
+++ b/mingw-w64-libraries/winpthreads/include/pthread.h
@@ -83,18 +83,17 @@ extern "C" {
 /* MSB 8-bit major version, 8-bit minor version, 16-bit patch level.  */
 #define __WINPTHREADS_VERSION 0x0005
 
-#ifdef IN_WINPTHREAD
-#  ifdef DLL_EXPORT
-#define WINPTHREAD_API __declspec(dllexport)
+#if defined(IN_WINPTHREAD)
+#  if defined(DLL_EXPORT)
+#define WINPTHREAD_API  __declspec(dllexport)  /* building the DLL  */
 #  else
-#define WINPTHREAD_API
+#define WINPTHREAD_API  /* building the static library  */
 #  endif
 #else
-#  ifdef WINPTHREAD_STATIC
-#define WINPTHREAD_API
+#  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 case of DLL  */
 #endif
 
 /* #define WINPTHREAD_DBG 1 */
diff --git a/mingw-w64-libraries/winpthreads/include/sched.h 
b/mingw-w64-libraries/winpthreads/include/sched.h
index 2f6ce7c49..8d0478413 100644
--- a/mingw-w64-libraries/winpthreads/include/sched.h
+++ b/mingw-w64-libraries/winpthreads/include/sched.h
@@ -49,18 +49,17 @@ struct sched_param {
 extern "C" {
 #endif
 
-#ifdef IN_WINPTHREAD
+#if defined(IN_WINPTHREAD)
 #  if defined(DLL_EXPORT) && !defined(WINPTHREAD_EXPORT_ALL_DEBUG)
-#define WINPTHREAD_SCHED_API __declspec(dllexport)
+#define WINPTHREAD_SCHED_API  __declspec(dllexport)  /* building the DLL  
*/
 #  else
-#define WINPTHREAD_SCHED_API
+#define WINPTHREAD_SCHED_API  /* building the static library  */
 #  endif
 #else
-#  ifdef WINPTHREAD_STATIC
-#define WINPTHREAD_SCHED_API
+#  if defined(WINPTHREADS_USE_DLLIMPORT)
+#define WINPTHREAD_SCHED_API  __declspec(dllimport)  /* user wants 
explicit `dllimport`  */
 #  else
-#define WINPTHREAD_SCHED_API __declspec(dllimport)
-#  endif
+#define WINPTHREAD_SCHED_API  /* the default; auto imported in case of DLL 
 */
 #endif
 
 int WINPTHREAD_SCHED_API sched_yield(void);
diff --git a/mingw-w64-libraries/winpthreads/include/semaphore.h 
b/mingw-w64-libraries/winpthreads/include/semaphore.h
index fb08d58d7..4d332e8b4 100644
--- a/mingw-w64-libraries/winpthreads/include/semaphore.h
+++ b/mingw-w64-libraries/winpthreads/include/semaphore.h
@@ -27,18 +27,17 @@
 extern "C" {
 #endif
 
-#ifdef IN_WINPTHREAD
+#if defined(IN_WINPTHREAD)
 #  if defined(DLL_EXPORT) && !defined(WINPTHREAD_EXPORT_ALL_DEBUG)
-#define WINPTHREAD_SEMA_API __declspec(dllexport)
+#define WINPTHREAD_SEMA_API  __declspec(dllexport)  /* building the DLL  */
 #  else
-#define WINPTHREAD_SEMA_API
+#define WINPTHREAD_SEMA_API  /* building the static library  */
 #  endif
 #else
-#  ifdef WINPTHREAD_STATIC
-#define WINPTHREAD_SEMA_API
+# 

Re: [Mingw-w64-public] winpthreads and gcc 7.1

[Daniel Santos]

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 prior to libgcc. That is the reason why we link
> against fake libs.
>
> Copying the libgcc function is not an option because everything has to
> be GPL thereafter.

Oh, I see. Well I guess that's why I didn't chime in earlier.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads and gcc 7.1

[Liu Hao]

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 
against fake libs.

Copying the libgcc function is not an option because everything has to 
be GPL thereafter.

-- 
Best regards,
LH_Mouse


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads and gcc 7.1

[Daniel Santos]

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 patch.
>>>
>> Works! Thanks! \o/
>>
> This is nothing but a quick fix. We might need a better solution, as we
> have discussed on IRC (others being ktietz and jacek) Windows does have
> some muldiv functions exported from ntdll, but at the moment I don't
> have time to look into them.

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.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads and gcc 7.1

[Liu Hao]

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 nothing but a quick fix. We might need a better solution, as we 
have discussed on IRC (others being ktietz and jacek) Windows does have 
some muldiv functions exported from ntdll, but at the moment I don't 
have time to look into them.

-- 
Best regards,
LH_Mouse


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads and gcc 7.1

[Christer Solskogen]

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



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads and gcc 7.1

[Liu Hao]

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 2017 15:52:32 +0800
Subject: [PATCH] winpthreads/src/clock.c: Fix undefined reference to
 `__divmoddi4'.

GCC targeting i686 _may_ generate an external call to the function in
question when divding a 64-bit (DIMode) integer with another one.
Since we are linking against a fake libgcc, this function is not available.
The functionality can be emulated by casting both operands to `double`
then performing trivial floating point division on them.

Signed-off-by: Liu Hao 
---
 mingw-w64-libraries/winpthreads/src/clock.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mingw-w64-libraries/winpthreads/src/clock.c 
b/mingw-w64-libraries/winpthreads/src/clock.c

index 5ad710b2..3cffdd46 100644
--- a/mingw-w64-libraries/winpthreads/src/clock.c
+++ b/mingw-w64-libraries/winpthreads/src/clock.c
@@ -134,8 +134,8 @@ int clock_gettime(clockid_t clock_id, struct 
timespec *tp)

 if (QueryPerformanceCounter(&pc) == 0)
 return lc_set_errno(EINVAL);

-tp->tv_sec = pc.QuadPart / pf.QuadPart;
-tp->tv_nsec = (int) (((pc.QuadPart % pf.QuadPart) * POW10_9 
+ (pf.QuadPart >> 1)) / pf.QuadPart);

+tp->tv_sec = (time_t)(pc.QuadPart / (double)pf.QuadPart);
+tp->tv_nsec = (int) (((__int64)(pc.QuadPart - tp->tv_sec * 
(double)pf.QuadPart) * POW10_9 + (pf.QuadPart >> 1)) / (double)pf.QuadPart);

 if (tp->tv_nsec >= POW10_9) {
 tp->tv_sec ++;
 tp->tv_nsec -= POW10_9;
--
2.12.1


From 4fa48b2af092a3b8615cef39b6e0036e20481c3f Mon Sep 17 00:00:00 2001
From: Liu Hao 
Date: Wed, 3 May 2017 15:52:32 +0800
Subject: [PATCH] winpthreads/src/clock.c: Fix undefined reference to
 `__divmoddi4'.

GCC targeting i686 _may_ generate an external call to the function in
question when divding a 64-bit (DIMode) integer with another one.
Since we are linking against a fake libgcc, this function is not available.
The functionality can be emulated by casting both operands to `double`
then performing trivial floating point division on them.

Signed-off-by: Liu Hao 
---
 mingw-w64-libraries/winpthreads/src/clock.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mingw-w64-libraries/winpthreads/src/clock.c 
b/mingw-w64-libraries/winpthreads/src/clock.c
index 5ad710b2..3cffdd46 100644
--- a/mingw-w64-libraries/winpthreads/src/clock.c
+++ b/mingw-w64-libraries/winpthreads/src/clock.c
@@ -134,8 +134,8 @@ int clock_gettime(clockid_t clock_id, struct timespec *tp)
 if (QueryPerformanceCounter(&pc) == 0)
 return lc_set_errno(EINVAL);
 
-tp->tv_sec = pc.QuadPart / pf.QuadPart;
-tp->tv_nsec = (int) (((pc.QuadPart % pf.QuadPart) * POW10_9 + 
(pf.QuadPart >> 1)) / pf.QuadPart);
+tp->tv_sec = (time_t)(pc.QuadPart / (double)pf.QuadPart);
+tp->tv_nsec = (int) (((__int64)(pc.QuadPart - tp->tv_sec * 
(double)pf.QuadPart) * POW10_9 + (pf.QuadPart >> 1)) / (double)pf.QuadPart);
 if (tp->tv_nsec >= POW10_9) {
 tp->tv_sec ++;
 tp->tv_nsec -= POW10_9;
-- 
2.12.1

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] winpthreads and gcc 7.1

[Christer Solskogen]

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-info 1:0:0 
-L./fakelib -Wc,-no-pthread  -o libwinpthread.la -rpath 
/home/solskogen/obj/cross-mingw-w64/i686-w64-mingw32/lib 
src/libwinpthread_la-barrier.lo src/libwinpthread_la-cond.lo 
src/libwinpthread_la-misc.lo src/libwinpthread_la-mutex.lo 
src/libwinpthread_la-rwlock.lo src/libwinpthread_la-spinlock.lo 
src/libwinpthread_la-thread.lo src/libwinpthread_la-ref.lo 
src/libwinpthread_la-sem.lo src/libwinpthread_la-sched.lo 
src/libwinpthread_la-clock.lo src/libwinpthread_la-nanosleep.lo 
src/version.lo
libtool: link: rm -fr  .libs/libwinpthread.dll.a
libtool: link: i686-w64-mingw32-gcc -shared 
src/.libs/libwinpthread_la-barrier.o src/.libs/libwinpthread_la-cond.o 
src/.libs/libwinpthread_la-misc.o src/.libs/libwinpthread_la-mutex.o 
src/.libs/libwinpthread_la-rwlock.o 
src/.libs/libwinpthread_la-spinlock.o 
src/.libs/libwinpthread_la-thread.o src/.libs/libwinpthread_la-ref.o 
src/.libs/libwinpthread_la-sem.o src/.libs/libwinpthread_la-sched.o 
src/.libs/libwinpthread_la-clock.o 
src/.libs/libwinpthread_la-nanosleep.o src/.libs/version.o   -L./fakelib 
  -O2 -no-pthread   -o .libs/libwinpthread-1.dll 
-Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker 
.libs/libwinpthread.dll.a
src/.libs/libwinpthread_la-clock.o:clock.c:(.text+0x270): undefined 
reference to `__divmoddi4'
collect2: error: ld returned 1 exit status
Makefile:670: recipe for target 'libwinpthread.la' failed
make[2]: *** [libwinpthread.la] Error 1
make[2]: Leaving directory 
'/tmp/obj/_build/winpthreads.cross.i686-w64-mingw32'
Makefile:866: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
'/tmp/obj/_build/winpthreads.cross.i686-w64-mingw32'
Makefile:477: recipe for target 'all' failed
make: *** [all] Error 2


   $ 
/home/solskogen/mingw-w64-builder/trunk/lib/mingw-w64/mingw-w64-libraries/winpthreads/configure
 
--build=x86_64-pc-linux-gnu 
--prefix=/home/solskogen/obj/cross-mingw-w64/i686-w64-mingw32 
--host=i686-w64-mingw32



Cross compiling to x86_64-w64-mingw32 works fine.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads, pthread_setschedparam, and detached threads

[K. Frank]

Hello Lefty!

On Tue, May 31, 2016 at 11:31 PM, lh mouse  wrote:
> Note that in most cases threads other than the one calling `pthread_detach()` 
> can terminate at anytime.
> ...

I would say your description fits the typical use case.

> By calling `pthread_detach()` on a `pthread_t` you _semantically_ 
> destroy/close it and should not use it any more.

Well, maybe.  I certainly don't find anything in the pthread standard that
justifies this semantic interpretation (nor that contradicts it).  I do expect
that many people look at it the way you do.

One can certainly imagine a use case where "using" a detached thread (and
calling pthread_setschedparam() on it) would make sense.  Detached threads
still respect synchronization objects (e.g., mutexes and condition variable, but
not pthread_join).  So maybe you have a detached thread servicing some sort
of queue (controlled by a condition variable) and you want to throttle it by
changing its priority, so you want to call pthread_setschedparam() on it.

Of course, you can easily work around this issue by not detaching the thread.

>
> Best regards,
> lh_mouse
> 2016-06-01


Happy Hacking!


> 发件人："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.  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 
> detached, or as part of the pthread_create() call.
> ...

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads, pthread_setschedparam, and detached threads

[lh mouse]

I think it would be a bug in your example. Were it not a bug there would be no 
way for a detached thread to operate itself.

--   
Best regards,
lh_mouse
2016-06-01

-
发件人："Burkhardt, Glenn 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(), SCHED_OTHER, ¶m);

but in winpthreads, for a detached thread, it will.  

> Re: [Mingw-w64-public] winpthreads, pthread_setschedparam, and detached 
> threads
> From: lh mouse - 2016-06-01 03:31:43

> Note that in most cases threads other than the one calling `pthread_detach()` 
> can terminate at anytime. After a call `pthread_detach()`, if the thread 
> terminates, its resources are freed automatically, rendering the `pthread_t` 
> no longer valid. It is impossible to tell whether a `pthread_t` is 
> designating a thread that has terminated. It may even be designating a thread 
> that is different from the one the user expects because thread IDs 
> can be reused.

> By calling `pthread_detach()` on a `pthread_t` you _semantically_ 
> destroy/close it and should not use it any more.

--   
Best regards,
lh_mouse
2016-06-01

-
发件人："Burkhardt, Glenn BUTAS" 
发送日期：2016-05-31 23:11
收件人：mingw-w64-public@...
抄送：
主题：[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.  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 
detached, or as part of the pthread_create() call.

Is there a reason for this?  For me, it's unexpected behavior.




--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads, pthread_setschedparam, and detached threads

[Burkhardt, Glenn B UTAS]

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
> From: lh mouse - 2016-06-01 03:31:43

> Note that in most cases threads other than the one calling `pthread_detach()` 
> can terminate at anytime. After a call `pthread_detach()`, if the thread 
> terminates, its resources are freed automatically, rendering the `pthread_t` 
> no longer valid. It is impossible to tell whether a `pthread_t` is 
> designating a thread that has terminated. It may even be designating a thread 
> that is different from the one the user expects because thread IDs 
> can be reused.

> By calling `pthread_detach()` on a `pthread_t` you _semantically_ 
> destroy/close it and should not use it any more.

--   
Best regards,
lh_mouse
2016-06-01

-
发件人："Burkhardt, Glenn BUTAS" 
发送日期：2016-05-31 23:11
收件人：mingw-w64-public@...
抄送：
主题：[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.  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 
detached, or as part of the pthread_create() call.

Is there a reason for this?  For me, it's unexpected behavior.




--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads, pthread_setschedparam, and detached threads

[lh mouse]

Note that in most cases threads other than the one calling `pthread_detach()` 
can terminate at anytime. After a call `pthread_detach()`, if the thread 
terminates, its resources are freed automatically, rendering the `pthread_t` no 
longer valid. It is impossible to tell whether a `pthread_t` is designating a 
thread that has terminated. It may even be designating a thread that is 
different from the one the user expects because thread IDs can be reused.
By calling `pthread_detach()` on a `pthread_t` you _semantically_ destroy/close 
it and should not use it any more.

--   
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_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.  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 
detached, or as part of the pthread_create() call.

Is there a reason for this?  For me, it's unexpected behavior.


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads, pthread_setschedparam, and detached threads

[K. Frank]

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 detached 
> threads can only be set once, at thread creation, before the thread is 
> detached, or as part of the pthread_create() call.
>
> Is there a reason for this?  For me, it's unexpected behavior.

I don't see anything in the pthreads documentation that makes clear
whether this should be allowed or not.  However, the error-code return
values for pthread_setschedparam() does not list an error value for
this situation, which perhaps is a hint that it should work.

On the other hand, there does seem to be precedent for this not working.

I found some documentation for DEC / VMS pthreads here:

   http://www.mi.infn.it/~calcolo/OpenVMS/ssb71/6493/6493p002.htm

Quoting from paragraph 2.3.4:

   It is illegal for your program to attempt any operation on a detached
   thread or to use any information in the thread object associated with
   a detached thread. For instance, a thread cannot join on a detached
   thread, and your program cannot cancel a detached thread.

So it sounds like the VMS implementation, at least, doesn't support calling
pthread_setschedparam() on a detached thread.

(I wonder if a detached thread calling pthread_setschedparam() on itself
could be an edge case in some implementations.)


Happy Hacking!


K. Frank

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] winpthreads, pthread_setschedparam, and detached threads

[Burkhardt, Glenn B UTAS]

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 
detached, or as part of the pthread_create() call.

Is there a reason for this?  For me, it's unexpected behavior.




--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads

[Mateusz]

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 );
*

And my riddle is: where is the spinlock?

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads

[Adrien Nader]

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.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads

[Mattias Engdegård]

> 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. That is, if the error is real and 
not due to a configuration mistake.


--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads

[Alexey Pavlov]

> 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 - 
> https://github.com/msys2/mingw-w64/commit/249898d9ae310959116efa333e4e3e690cf97452
>  
> 
> Rewrite the mutex implementation for better performance - 
> https://github.com/msys2/mingw-w64/commit/1968e60cd5d59727bb325d5b69c8f0d7a2f1fe1b
>  
> 
> 
> I have no yet good testcase. This is GDB backtrace from one of our users 
> https://gist.github.com/achadwick/01c6a1b519a36dcdbe0a 
> 
> 
> Regards,
> Alexey.
> 
> 

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.

Regards,
Alexey.--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] winpthreads

[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 - 
https://github.com/msys2/mingw-w64/commit/249898d9ae310959116efa333e4e3e690cf97452
 

Rewrite the mutex implementation for better performance - 
https://github.com/msys2/mingw-w64/commit/1968e60cd5d59727bb325d5b69c8f0d7a2f1fe1b
 


I have no yet good testcase. This is GDB backtrace from one of our users 
https://gist.github.com/achadwick/01c6a1b519a36dcdbe0a 


Regards,
Alexey.


--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Winpthreads slow mutexes - still applies?

[K. Frank]

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 cleared for release yet. It may 
> take a few weeks more, given that people are on holiday. I shall try to 
> accelerate the process.
> ...

Out of curiosity, do you know what approach the patch takes?
I ask because std::thread supports timed waits on (timed) mutexes,
and I believe that pthreads does as well.  How does the patch
implement timed waits?

Quoting from the bug report cited above:

   Currently libwinpthread implements mutexes directly on top
   of Windows semaphores. Semaphores, being kernel objects,
   require kernel mode transition in order to lock or unlock, which
   is very slow compared to interlocked operations (as in, "up to
   several hundred times slower").

   Suggestion: either base mutexes on Windows critical sections
   outright, or do the same thing "manually".

If the solution is to base winpthread's mutexes on windows
critical sections, you will have to address the issue of timed
waits.  I believe that windows critical sections offer no timed
wait functionality.

I see three ways to address this.  Use critical sections as mutexes,
but add additional helper objects (that support waits) to any timed
wait call.  I think this is doable, but seems unattractively complicated
and will worsen performance.

Write from scratch (i.e. don't use windows critical sections) your
own mutexes that support timed waits.  This ought to be doable,
but would be some work and does seem like reinventing the wheel.
(But, as I understand it, winpthread did write its own condition
variables from scratch.)

Recognize that std::thread (I don't know if this applies to pthreads
or not) distinguishes between timed mutexes (that you can perform
a timed wait on) and "regular" mutexes that do not support timed
waits.  In this case you could, for example, base "regular" mutexes
on windows critical sections (no timed waits), and timed mutexes
on windows semaphores (or windows mutexes).  This has the
disadvantage that you now have two different kinds of mutexes.
(Why shouldn't you be able to perform a timed wait on any mutex?),
but the "regular" mutexes should now be faster.

I should note that both windows semaphores and windows mutexes
(Both support timed waits.) are cross-process synchronization
objects, whereas windows critical sections can only be used to
synchronize threads within a single process (consistent with the
single-process threading model supported by std::thread and
pthreads).  As cross-process objects they are heavier weight and
less efficient, and this probably accounts for the mutex inefficiency
described in the bug report.


Best.


K. Frank

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Winpthreads slow mutexes - still applies?

[Mattias Engdegård]

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 holiday. I shall try to accelerate 
the process.


--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Winpthreads slow mutexes - still applies?

[Alexandre Pereira Nunes]

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.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads cleanup handlers not called afterpthread_exit()

[Keri Harris]

On 21/03/2015 12:39, Victor Bombi wrote:
> May be it has some relation with?
>
> http://sourceforge.net/p/mingw-w64/mailman/message/31749147/

I don't think it's related; this has to do with explicit calls to 
thread_exit() not invoking cleanup handlers that were registered via 
pthread_cleanup_push().

Looking at the definition for pthread_cleanup_push() in 
winpthreads/include/pthread.h, it looks like the cleanup stack is only 
accessible via a local variable, and no mechanism exists to call these 
handlers unless pthread_cleanup_pop() is explicitly called. 
pthreads-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-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:
>>
>>  The cancellation cleanup handler shall be popped from the
>> cancellation cleanup stack
>>  and invoked with the argument arg when:
>>
>>  The thread exits (that is, calls pthread_exit()).
>>
>> An example program illustrating winpthreads failing to invoke cleanup
>> handlers follows:
>>
>>
>> #include 
>> #include 
>>
>> void* cleanup_func(void *arg)
>> {
>>  printf("cleanup_func()\n");
>> }
>>
>> void* func(void *arg)
>> {
>>  printf("func()\n");
>>  pthread_cleanup_push(cleanup_func, 0);
>>  pthread_exit(NULL);
>>  pthread_cleanup_pop(1);
>> }
>>
>> int main()
>> {
>>  pthread_t t;
>>  void *ret;
>>
>>  pthread_create(&t, NULL, func, (void*)NULL);
>>  pthread_join(t, &ret);
>>
>>  return 0;
>> }
>>
>>
>>
>> Thanks
>>
>> Keri
>>
>> [1]
>> http://pubs.opengroup.org/onlinepubs/95399/functions/pthread_cleanup_pop.html
>>
>>
>> --
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for
>> all
>> things parallel software development, from weekly thought leadership blogs
>> to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads cleanup handlers not called afterpthread_exit()

[Victor Bombi]

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:
>
> The cancellation cleanup handler shall be popped from the
> cancellation cleanup stack
> and invoked with the argument arg when:
>
> The thread exits (that is, calls pthread_exit()).
>
> An example program illustrating winpthreads failing to invoke cleanup
> handlers follows:
>
>
> #include 
> #include 
>
> void* cleanup_func(void *arg)
> {
> printf("cleanup_func()\n");
> }
>
> void* func(void *arg)
> {
> printf("func()\n");
> pthread_cleanup_push(cleanup_func, 0);
> pthread_exit(NULL);
> pthread_cleanup_pop(1);
> }
>
> int main()
> {
> pthread_t t;
> void *ret;
>
> pthread_create(&t, NULL, func, (void*)NULL);
> pthread_join(t, &ret);
>
> return 0;
> }
>
>
>
> Thanks
>
> Keri
>
> [1]
> http://pubs.opengroup.org/onlinepubs/95399/functions/pthread_cleanup_pop.html
>
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website, 
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for 
> all
> things parallel software development, from weekly thought leadership blogs 
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public 


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] winpthreads cleanup handlers not called after pthread_exit()

[Keri Harris]

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:

 The cancellation cleanup handler shall be popped from the 
cancellation cleanup stack
 and invoked with the argument arg when:

 The thread exits (that is, calls pthread_exit()).

An example program illustrating winpthreads failing to invoke cleanup 
handlers follows:


#include 
#include 

void* cleanup_func(void *arg)
{
 printf("cleanup_func()\n");
}

void* func(void *arg)
{
 printf("func()\n");
 pthread_cleanup_push(cleanup_func, 0);
 pthread_exit(NULL);
 pthread_cleanup_pop(1);
}

int main()
{
 pthread_t t;
 void *ret;

 pthread_create(&t, NULL, func, (void*)NULL);
 pthread_join(t, &ret);

 return 0;
}



Thanks

Keri

[1] 
http://pubs.opengroup.org/onlinepubs/95399/functions/pthread_cleanup_pop.html


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] winpthreads busyloops indefinitely when destroying a mutex

[LRN]

-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 conclusion that r6482 is not a good idea, and that
winpthreads must only destroy mutexes that have zero references to them.

After that i went back to r6481 and found the reason why winpthreads
busylooped indefinitely. It locked the global spinlock, while trying
to ref a mutex before destroying it, and failed to release it.

The patch against r6481 is attached.

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJS/fWLAAoJEOs4Jb6SI2Cw3goIANLVGfqNM/5jUbK6GcoaqorC
yH8g8g/sjwYnjTY6d82OneirhyWrpBo7Z+rSCpEfvXIirh89qaEnC90TRJV3TfIP
NN1sX/OZbvciosOC115qYPt0WVehRS65tr49AB0ap+yC796NN0SfUGeXaJGpdzuV
kp7sGxR9VzDB6R3wu9dFISK1Lc6QPkoAtDCruzJEu5JGQxMNUjjtiA7KQMTfuil7
LQWv3hpRo1fXHBgSXQJFuRQpfCQ5hGvnYqacv+cE4tGjrlIjBlKPyaN29OOebqr4
8wTjzY+BFbrg7f08Tduw2nlO5iWKxpQJQtkp10Hf7zTHUW7QPdHGddYvk4HxKJk=
=M+5b
-END PGP SIGNATURE-
Index: src/mutex.c
===
--- src/mutex.c	(revision 6481)
+++ src/mutex.c	(working copy)
@@ -144,7 +144,7 @@
 else if (m_->valid != LIFE_MUTEX)
   r = EINVAL;
 else if (m_->busy)
-  return 0xbeef; /* Indicate we want to wait here.  */
+  r = 0xbeef; /* Indicate we want to wait here.  */
 else if (COND_LOCKED(m_))
   r = EBUSY;
 else
--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Winpthreads library issue with dwarf toolchain

[JonY]

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
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Winpthreads library issue with dwarf toolchain

[Kai Tietz]

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 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Winpthreads library issue with dwarf toolchain

[Alexey Pavlov]

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/clk?id=111408631&iu=/4140/ostg.clktrk
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads kill

[Alexpux]

09 дек. 2013 г., в 23:42, Victor Bombi  написал(а):

> ok. I have got msys and I need to build a debug version of winpthreads for 
> debugging a program that is hanging on exit (only the windows version)
> I do ./configure --help but I cant understand how to build a debug version.
> Any hints?

You can see how we build it for our toolchain
https://github.com/Alexpux/mingw-builds/blob/develop/scripts/winpthreads.sh#L54-L65

To build debug version you can guid with CFLAGS="-O0 -g»

Regards,
Alexey.
> 
> victor
> 
> - Original Message - 
> From: "Victor 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?
>> 
>> - Original Message - 
>> From: "JonY" 
>> To: 
>> Sent: Wednesday, November 27, 2013 11:10 PM
>> Subject: Re: [Mingw-w64-public] winpthreads kill
>> 
>> 
>>> --
>>> Rapidly troubleshoot problems before they affect your business. Most IT
>>> organizations don't have a clear picture of how application performance
>>> affects their revenue. With AppDynamics, you get 100% visibility into 
>>> your
>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>>> Pro!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>> 
>> 
>> 
>> 
>> 
>>> ___
>>> Mingw-w64-public mailing list
>>> Mingw-w64-public@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>> 
>> 
>> 
>> --
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics 
>> Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public 
> 
> 
> --
> 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
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
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
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads kill

[Victor Bombi]

ok. I have got msys and I need to build a debug version of winpthreads for 
debugging a program that is hanging on exit (only the windows version)
I do ./configure --help but I cant understand how to build a debug version.
Any hints?

victor

- Original Message - 
From: "Victor 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?
>
> - Original Message - 
> From: "JonY" 
> To: 
> Sent: Wednesday, November 27, 2013 11:10 PM
> Subject: Re: [Mingw-w64-public] winpthreads kill
>
>
>> --
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into 
>> your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>
>
> 
>
>
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>
>
> --
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics 
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public 


--
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
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Winpthreads library issue with dwarf toolchain

[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/clk?id=111408631&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Winpthreads library issue with dwarf toolchain

[Fanael Linithien]

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 dw :
> 1) Shouldn't global_lock be __LONG32?

Probably not. InterlockedExchange takes volatile LONG*.

> 2) Would it make sense for the exchange on global_lock to be done as a
> single operation (ie InterlockedCompareExchange)?

It's not necessary. InterlockedExchange already provides enough synchronization.

--
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
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Winpthreads library issue with dwarf toolchain

[dw]

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 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 a mutex, which requires a
spinlock, which needs to be initialized in static_spin_init, which
tries to enter the global critical section, which is not initialized.
The result is a segfault somewhere in ntdll.

register_frame_ctor has constructor priority of 0, so setting the
priority of global_spin_ctor wouldn't cut it.


I'm not sure what is the official way to send patches, so I'm posting it here.


--
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


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
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___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Winpthreads library issue with dwarf toolchain

[Kai Tietz]

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
> runs BEFORE enter_global_cs, tries to lock a mutex, which requires a
> spinlock, which needs to be initialized in static_spin_init, which
> tries to enter the global critical section, which is not initialized.
> The result is a segfault somewhere in ntdll.
>
> register_frame_ctor has constructor priority of 0, so setting the
> priority of global_spin_ctor wouldn't cut it.
>
>
> I'm not sure what is the official way to send patches, so I'm posting it here.

Nice catch.  This describes at least the runtime-failure we got reported.
Did you tested regressions for this patch?

The only thing about using memory-based spinlocking is that we might
introduce race-condtion.  So we should at least verify for this.

Kai

--
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
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Winpthreads library issue with dwarf toolchain

[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
runs BEFORE enter_global_cs, tries to lock a mutex, which requires a
spinlock, which needs to be initialized in static_spin_init, which
tries to enter the global critical section, which is not initialized.
The result is a segfault somewhere in ntdll.

register_frame_ctor has constructor priority of 0, so setting the
priority of global_spin_ctor wouldn't cut it.


I'm not sure what is the official way to send patches, so I'm posting it here.


spinlock-remove-ctor.patch
Description: Binary data
--
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___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Winpthreads library issue with dwarf toolchain

[niXman]

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 debuginfo
> and has next GDB backtrace http://pastebin.com/8pdYsY3f.
> 
> If anyone has ability to resolve it I upload archive with breaked
> winpthreads+sqlite:
> https://www.dropbox.com/s/1wgqzvbcy0230h3/debug.tar.bz2

ping?


-- 
Regards, niXman
___
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingw-w64/
___
Another online IDE: http://liveworkspace.org/

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads kill

[Victor Bombi]

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] winpthreads kill


> --
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics 
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk





> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> 


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Winpthreads library issue with dwarf toolchain

[Alexey Pavlov]

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.com/8pdYsY3f.

If anyone has ability to resolve it I upload archive with breaked
winpthreads+sqlite:
https://www.dropbox.com/s/1wgqzvbcy0230h3/debug.tar.bz2


Regards,
Alexey.

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads kill

[JonY]

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 for development
> versions anymore.
> 

Trunk includes some updates, so please do try it.





signature.asc
Description: OpenPGP digital signature
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads kill

[Ruben Van Boxem]

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


>
>
> --
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads kill

[Jon]

>
> 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 IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] winpthreads kill

[Victor Bombi]

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 


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads testsuite

[NightStrike]

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 are tracked in SVN).
>>
>
> OK, here is a better patch - split into parts, without generated
> files. Say "think you" to git-svn and its wonderful awesomeness!

We have two testsuite directories, "test" and "tests".  I renamed
"tests" to "tests-pthreads" since it comes directly from them.  I
renamed "test" to "tests" and have begun integrating it with the
build.  Next step will be to integrate the other suite.

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads testsuite

[Jim Michaels]

 I have a 12-thread windows machine if you want to test it on that. behavior 
could be more interesting with more threads...

hopefully it's killable or terminates itself.
if you have a complete binary package with all dlls and such I could test it on 
my box and let you know how it goes. I 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
> 
>
>-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, 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?
>>> No. Ktietz gave me a patch, but it didn't fix the bug.
>>> 
>>>> (Sorry to semi-hijack the current thread.)
>>> One of the reasons why i want testsuite is that create2, in 
>>> particular, fails due to the create/join race. So it's not that
>>> bad :) ...
>> 
>> How frequently does the race occur?
>> 
>> The reason I ask is that I've used a couple of mingw-w64 builds
>> where std::thread is implemented on top of winpthreads.  I didn't
>> try any raw winpthreads create / join tests, but I did do the
>> equivalent at the std::thread level, namely instantiate / join some
>> std::threads.  When I ran my elementary (and not particularly
>> high-stress) join tests I didn't see any problems.  (This was on a
>> two-core windows 7 machine.)
>> 
>> So I'm wondering if the bug you found is relatively rare, or
>> whether I would need to run a more sophisticated test to catch it.
>> (Or maybe whether the specific std::thread use case avoids it
>> somehow.)
>As i have said, new testsuite triggers that bug for me (create2 test).
>
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v1.4.11 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iQEcBAEBAgAGBQJRat32AAoJEOs4Jb6SI2CwDNgIAL5XZGDZbfbCffTRdxIA4LoT
>St+DavJxeZ6O7kX9MPG8h322q32oGMd73woBLCMpbIDRlGE+h4BkkiqHpjrSr53m
>+7NOa9NCbrI1LAYL0Frh4i8sa11fMeiVjSOreFclqUn5D82x45kBzdwToQDE5u1o
>T/P4ctGMA+i+1q9r4U0PhAqzKNkHQK+aw4wKxmeDhqJco3OQmg5nUc1vLEqAtaG3
>S3Uee1x3fL51YO05qBnUNWgjDWs0njSVW+zPOTJRJtVufXICdLGAFGBBxaJ54fJs
>QcIRPSqqA78DIhkPe5FPfP+9fravJ2KR0schFFAKQ7oh5VMawF4AA2dCp4L0R8Q=
>=+NeW
>-END PGP SIGNATURE-
>
>--
>Precog is a next-generation analytics platform capable of advanced
>analytics on semi-structured data. The platform includes APIs for building
>apps and a phenomenal toolset for data science. Developers can use
>our toolset for easy data analysis & visualization. Get a free account!
>http://www2.precog.com/precogplatform/slashdotnewsletter
>___
>Mingw-w64-public mailing list
>Mingw-w64-public@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
>--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads testsuite

[Antony Riakiotakis]

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 platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads testsuite

[LRN]

-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, 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?
>> No. Ktietz gave me a patch, but it didn't fix the bug.
>> 
>>> (Sorry to semi-hijack the current thread.)
>> One of the reasons why i want testsuite is that create2, in 
>> particular, fails due to the create/join race. So it's not that
>> bad :) ...
> 
> How frequently does the race occur?
> 
> The reason I ask is that I've used a couple of mingw-w64 builds
> where std::thread is implemented on top of winpthreads.  I didn't
> try any raw winpthreads create / join tests, but I did do the
> equivalent at the std::thread level, namely instantiate / join some
> std::threads.  When I ran my elementary (and not particularly
> high-stress) join tests I didn't see any problems.  (This was on a
> two-core windows 7 machine.)
> 
> So I'm wondering if the bug you found is relatively rare, or
> whether I would need to run a more sophisticated test to catch it.
> (Or maybe whether the specific std::thread use case avoids it
> somehow.)
As i have said, new testsuite triggers that bug for me (create2 test).

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRat32AAoJEOs4Jb6SI2CwDNgIAL5XZGDZbfbCffTRdxIA4LoT
St+DavJxeZ6O7kX9MPG8h322q32oGMd73woBLCMpbIDRlGE+h4BkkiqHpjrSr53m
+7NOa9NCbrI1LAYL0Frh4i8sa11fMeiVjSOreFclqUn5D82x45kBzdwToQDE5u1o
T/P4ctGMA+i+1q9r4U0PhAqzKNkHQK+aw4wKxmeDhqJco3OQmg5nUc1vLEqAtaG3
S3Uee1x3fL51YO05qBnUNWgjDWs0njSVW+zPOTJRJtVufXICdLGAFGBBxaJ54fJs
QcIRPSqqA78DIhkPe5FPfP+9fravJ2KR0schFFAKQ7oh5VMawF4AA2dCp4L0R8Q=
=+NeW
-END PGP SIGNATURE-

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads testsuite

[K. Frank]

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 winpthreads. ...
>>
>> Did you ever learn more about  / sort out the create / join race
>> condition you reported earlier?
> No. Ktietz gave me a patch, but it didn't fix the bug.
>
>> (Sorry to semi-hijack the current thread.)
> One of the reasons why i want testsuite is that create2, in
> particular, fails due to the create/join race. So it's not that bad :)
> ...

How frequently does the race occur?

The reason I ask is that I've used a couple of mingw-w64 builds where
std::thread is implemented on top of winpthreads.  I didn't try any raw
winpthreads create / join tests, but I did do the equivalent at the
std::thread level, namely instantiate / join some std::threads.  When
I ran my elementary (and not particularly high-stress) join tests I didn't
see any problems.  (This was on a two-core windows 7 machine.)

So I'm wondering if the bug you found is relatively rare, or whether I
would need to run a more sophisticated test to catch it.  (Or maybe
whether the specific std::thread use case avoids it somehow.)

Thanks.


K. Frank

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads testsuite

[LRN]

-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 create / join race 
> condition you reported earlier?
No. Ktietz gave me a patch, but it didn't fix the bug.

> (Sorry to semi-hijack the current thread.)
One of the reasons why i want testsuite is that create2, in
particular, fails due to the create/join race. So it's not that bad :)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRaro5AAoJEOs4Jb6SI2CwxdEIAKcvVcgoV4tuZN8OyNNcaHjz
e6t+gPpKM+gXMtmoBAi2b0YrQzaHTmVwqpokDygvs4e4sA7GwG5qQzRqal0LuA3h
SAnDeNlMV0QLvnAmb57Hb0jIWS0pVc36JpIB0mSh6Xk8yXyFw8eJEGe+pM7/htBE
tNzEwN+7lDn8uibUX88GDoxjyjCZUOdcJ9MrWsAB8/O6GwgrXQcpesl+/WjNQjE/
DBBIy41O7KjZqcsQ+v9rJ3iyBGATrDw9IaiI7SPbR3RrSJr6LNDLH9wWXk57UuQW
CdCDswb8fDShU0KQxgueGwZbCGxJNgrGgTUouKOg91UNr+tp2rgl4HYecYFut10=
=DJIW
-END PGP SIGNATURE-

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads testsuite

[K. Frank]

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 thread.)

Thanks.


K. Frank

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads testsuite

[LRN]

-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 - split into parts, without generated
files. Say "think you" to git-svn and its wonderful awesomeness!

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRaqqYAAoJEOs4Jb6SI2CwVOQH/iQJq/QHNUGJJfjfr6aj2afS
GCskdC8Hr3XvTSSltTx38UfvM8alQaKE2W+T21JakjHk380IYm6paqN/4LpB9lul
iM13Uu2SQiw7iZ6o5YHvuHgahMcCB+JpbtkcF6Ac5Egu/BEodQnp3tD73D19m5xo
jU7eJutnGneBjG1JCwaxTsNrD2IHujvkX1NpQp9P6TAw/Y6wpi7DmQ6gIReQVWgy
i3mpHIdRjlj5qY1R752o+ttKDXdVfkn7X3c96mR9rU6AdHwsaOIap9vwcmQRHRDt
GXV2F/v8NqbISTTZeeSJWcwQYtxDjHyoum+8THpDUj0D2h20oF+Gl5/hGbYcrzo=
=wWKE
-END PGP SIGNATURE-
From b10962796e7dbd89718a964edec9db9b58760c26 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A0=D1=83=D1=81=D0=BB=D0=B0=D0=BD=20=D0=98=D0=B6=D0=B1?=
 =?UTF-8?q?=D1=83=D0=BB=D0=B0=D1=82=D0=BE=D0=B2?= 
Date: Sun, 14 Apr 2013 14:21:20 +0400
Subject: [PATCH 1/3] Integrate the testsuite

---
 Makefile.am   |  2 ++
 configure.ac  | 11 +-
 tests/Makefile.am | 66 +++
 3 files changed, 78 insertions(+), 1 deletion(-)
 create mode 100644 tests/Makefile.am

diff --git a/Makefile.am b/Makefile.am
index f117785..f57a553 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -33,6 +33,8 @@ libpthread_dll_a_DEPENDENCIES = libwinpthread.la
 libpthread_dll_a_SOURCES =
 endif
 
+SUBDIRS = tests
+
 # Tell libtool how to use the resource compiler
 .rc.lo:
$(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --tag=RC --mode=compile 
$(RC) $(RCFLAGS) -i $< -o $@
diff --git a/configure.ac b/configure.ac
index b579286..40c3449 100644
--- a/configure.ac
+++ b/configure.ac
@@ -53,5 +53,14 @@ AC_TYPE_SIZE_T
 
 AC_SUBST([RCFLAGS])
 
-AC_CONFIG_FILES([Makefile])
+AC_MSG_CHECKING(if benchmarking tests should be run)
+AC_ARG_ENABLE(
+  [benchmarks],
+  [AS_HELP_STRING([--enable-benchmarks], [enable benchmarking tests])],
+  [enable_benchmarks=${enableval}],
+  [enable_benchmarks=no])
+AC_MSG_RESULT($enable_benchmarks)
+AM_CONDITIONAL([ENABLE_BENCHMARKS], [test "x$enable_benchmarks" = "xyes"])
+
+AC_CONFIG_FILES([Makefile tests/Makefile])
 AC_OUTPUT
diff --git a/tests/Makefile.am b/tests/Makefile.am
new file mode 100644
index 000..8aed465
--- /dev/null
+++ b/tests/Makefile.am
@@ -0,0 +1,66 @@
+INCLUDES = -I$(top_srcdir)/include
+
+LDADD = $(top_builddir)/libwinpthread.la
+
+noinst_LTLIBRARIES = \
+  libbench.la
+libbench_la_SOURCES = \
+  benchlib.c
+libbench_la_LIBADD = \
+  $(LDADD)
+
+if ENABLE_BENCHMARKS
+  BENCHMARKS = benchtest1 benchtest2 benchtest3 benchtest4 benchtest5
+else
+  BENCHMARKS = 
+endif
+
+TESTS = \
+   sizes  loadfree \
+   self1  mutex5  \
+   mutex1  mutex1n  mutex1e  mutex1r  \
+   semaphore1  semaphore2  semaphore3  \
+   mutex2  mutex3  \
+   mutex2r  mutex2e  mutex3r  mutex3e  \
+   condvar1  condvar1_1  condvar1_2  condvar2  condvar2_1  \
+   exit1  create1  create2  reuse1  reuse2  equal1  \
+   kill1  valid1  valid2  \
+   exit2  exit3  exit4  exit5  \
+   join0  join1  detach1  join2 join3  \
+   mutex4  mutex6  mutex6n  mutex6e  mutex6r  \
+   mutex6s  mutex6es  mutex6rs  \
+   mutex7  mutex7n  mutex7e  mutex7r  \
+   mutex8  mutex8n  mutex8e  mutex8r  \
+   count1  \
+   once1  once2  once3  once4  \
+   self2  \
+   cancel1  cancel2  \
+   semaphore4  semaphore4t  semaphore5  \
+   barrier1  barrier2  barrier3  barrier4  barrier5  barrier6  \
+   tsd1  tsd2  delay1  delay2  eyal1  \
+   condvar3  condvar3_1  condvar3_2  condvar3_3  \
+   condvar4  condvar5  condvar6  \
+   condvar7  condvar8  condvar9  \
+   errno1  \
+   rwlock1  rwlock2  rwlock3  rwlock4  \
+   rwlock5  rwlock6  rwlock7  rwlock8  \
+   rwlock2_t  rwlock3_t  rwlock4_t  rwlock5_t  rwlock6_t  rwlock6_t2  \
+   context1  \
+   cancel3  cancel4  cancel5  cancel6a  cancel6d  \
+   cancel7  cancel8  \
+   cleanup0  cleanup1  cleanup2  cleanup3  \
+   priority1 priority2 inherit1  \
+   spin1  spin2  spin3  spin4  \
+   exception1  exception2  exception3  \
+   cancel9  create3  stress1 \
+$(BENCHMARKS)
+
+cancel9_LDADD = $(LDADD) -lws2_32
+
+benchtest1_LDADD = $(LDADD) libbench.la
+benchtest2_LDADD = $(LDADD) libbench.la
+benchtest3_LDADD = $(LDADD) libbench.la
+benchtest4_LDADD = $(LDADD) libbench.la
+benchtest5_LDADD = $(LDADD) libbench.la
+
+noinst_PROGRAMS = $(TESTS)
-- 
1.8.0.3

From 4a2a7122823df8c30179fa5cc6a6f6b118e7788b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A0=D1=83=D1=81=D0=BB=D0=B0=D0=BD=20=D0=98=D0=B6=D0=B1?=
 =?UTF-8?q?=D1=83=D0=BB=D0=B0=D1=82=D0=BE=D0=B2?= 
Date: Sun, 14 

[Mingw-w64-public] winpthreads testsuite

[LRN]

-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: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRalKVAAoJEOs4Jb6SI2CwO2MIANWhOAKaWR9gUulEYdTtFjvw
t9Gp3vfDBikBEsuqHDfrLvlc14j46sS/lf+RwjsYD+VtXa5c4eKl3Ri1DvRgh9oE
Veclc6rsYtXSWgFdPNUdEvdhhEpfdBWibekx5M3QxmMe23/0TvonHWnhvCq3D95S
VSoE7WxFls7iAEXeUkGxIHsVb8Xgz4+Vtf4wKM4KRVy4zA0EwLlneqkerJo9lsnz
mVyubNcQkIbh/GMCXLUPHnKb2vyDUT1CHDoF4fQoo/4issO/Xl4GMUggwNvZ0qVk
M+XhG/azX1Ig5PG+ZbiQsVBMK/A9X636alqlW9sanN9AbFnkB+JLnZRgSQNqFCw=
=kOzC
-END PGP SIGNATURE-
Index: configure
===
--- configure	(revision 5792)
+++ configure	(working copy)
@@ -637,6 +637,8 @@
 am__EXEEXT_TRUE
 LTLIBOBJS
 LIBOBJS
+ENABLE_BENCHMARKS_FALSE
+ENABLE_BENCHMARKS_TRUE
 RCFLAGS
 COPY_STATIC_FALSE
 COPY_STATIC_TRUE
@@ -778,6 +780,7 @@
 with_gnu_ld
 with_sysroot
 enable_libtool_lock
+enable_benchmarks
 '
   ac_precious_vars='build_alias
 host_alias
@@ -1423,6 +1426,7 @@
   --enable-fast-install[=PKGS]
   optimize for fast installation [default=yes]
   --disable-libtool-lock  avoid locking (might break parallel builds)
+  --enable-benchmarks enable benchmarking tests
 
 Optional Packages:
   --with-PACKAGE[=ARG]use PACKAGE [ARG=yes]
@@ -2196,7 +2200,7 @@
   || { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "failed to load site script $ac_site_file
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
   fi
 done
 
@@ -2422,11 +2426,11 @@
 '
 case `pwd` in
   *[\\\"\#\$\&\'\`$am_lf]*)
-as_fn_error $? "unsafe absolute working directory name" "$LINENO" 5;;
+as_fn_error $? "unsafe absolute working directory name" "$LINENO" 5 ;;
 esac
 case $srcdir in
   *[\\\"\#\$\&\'\`$am_lf\ \	]*)
-as_fn_error $? "unsafe srcdir value: '$srcdir'" "$LINENO" 5;;
+as_fn_error $? "unsafe srcdir value: '$srcdir'" "$LINENO" 5 ;;
 esac
 
 # Do 'set' in a subshell so we don't clobber the current shell's
@@ -2897,7 +2901,7 @@
 $as_echo "$ac_cv_build" >&6; }
 case $ac_cv_build in
 *-*-*) ;;
-*) as_fn_error $? "invalid value of canonical build" "$LINENO" 5;;
+*) as_fn_error $? "invalid value of canonical build" "$LINENO" 5 ;;
 esac
 build=$ac_cv_build
 ac_save_IFS=$IFS; IFS='-'
@@ -2930,7 +2934,7 @@
 $as_echo "$ac_cv_host" >&6; }
 case $ac_cv_host in
 *-*-*) ;;
-*) as_fn_error $? "invalid value of canonical host" "$LINENO" 5;;
+*) as_fn_error $? "invalid value of canonical host" "$LINENO" 5 ;;
 esac
 host=$ac_cv_host
 ac_save_IFS=$IFS; IFS='-'
@@ -3250,7 +3254,7 @@
 test -z "$CC" && { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "no acceptable C compiler found in \$PATH
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
 
 # Provide some information about the compiler.
 $as_echo "$as_me:${as_lineno-$LINENO}: checking for C compiler version" >&5
@@ -3388,7 +3392,7 @@
 { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error 77 "C compiler cannot create executables
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
 else
   { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
 $as_echo "yes" >&6; }
@@ -3431,7 +3435,7 @@
   { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot compute suffix of executables: cannot compile and link
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
 fi
 rm -f conftest conftest$ac_cv_exeext
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_exeext" >&5
@@ -3490,7 +3494,7 @@
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot run C compiled programs.
 If you meant to cross compile, use \`--host'.
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
 fi
   fi
 fi
@@ -3544,7 +3548,7 @@
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot run C compiled programs.
 If you meant to cross compile, use \`--host'.
-See \`config.log' for more details" "$LINENO" 5; }
+See \`config.log' for more details" "$LINENO" 5 ; }
 fi
   fi
 fi
@@ -3595,7 +3599,7 @@
 { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
 as_fn_error $? "cannot compute suffix of object files: cannot compile
-See \`config.log' for more detail

Re: [Mingw-w64-public] winpthreads patch for pthread_getspecific()/pthread_setspecific() function for restore WIN last error code

[niXman]

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 C { ~C() {} };
int Test() {
C t;
return ::GetLastError();
}
int main(int, const char**) {
::SetLastError(2);
return Test()-2;
}


Test for patch for pthread_setspecific().
Without the patch, main() return -2.

#include 
struct S {
~S() {
SetLastError(2);
}
};
void foo() {
S();
}
int main() {
foo();
return GetLastError()-2;
}



-- 
Regards,
niXman
___
Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows:
http://sourceforge.net/projects/mingwbuilds/

--
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 endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads patch for pthread_getspecific()/pthread_setspecific() function for restore WIN last error code

[Ozkan Sezer]

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 brokenness without
the change, and showing the healthiness with the change applied.
The existing tests in winpthreads are examples.

--
O.S.

--
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 endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads patch for pthread_getspecific()/pthread_setspecific() function for restore WIN last error code

[niXman]

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) MinGW compilers for 32 and 64 bit Windows:
http://sourceforge.net/projects/mingwbuilds/

--
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 endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads patch for pthread_getspecific()/pthread_setspecific() function for restore WIN last error code

[Kai Tietz]

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

--
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 endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads patch for pthread_getspecific()/pthread_setspecific() function for restore WIN last error code

[niXman]

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/

--
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 endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads patch for pthread_getspecific()/pthread_setspecific() function for restore WIN last error code

[niXman]

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 and 64 bit Windows:
http://sourceforge.net/projects/mingwbuilds/
rm -f *.dll
rm -f *.lib
rm -f pthread.h
rm -f semaphore.h
rm -f sched.h
rm -f *.a
rm -f *.e
rm -f *.i
rm -f *.o
rm -f *.so
rm -f *.obj
rm -f *.pdb
rm -f *.exe
rm -f *.pass
rm -f *.fail
rm -f *.x
rm -f *.bench
rm -f *.static
rm -f *.log
Copying ../.libs/libwinpthread.dll.a
Copying ../.libs/libwinpthread-1.dll
make -k TEST=GC CC=-gcc XXCFLAGS="-D__CLEANUP_C" all-pass
make[1]: Entering directory `/usr/home/niXman/build/tests'
Compiling runall.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o runall.exe runall.c -I./include 
-L../outlib -lwinpthread -lsupc++ -lws2_32
Running runall
./runall
usage: runall 
Passed
Compiling sizes.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o sizes.exe sizes.c -I./include 
-L../outlib -lwinpthread -lsupc++ -lws2_32
Running
./sizes.exe > SIZES.GC
Sizes of winpthreads structs
---
 pthread_t4
   pthread_attr_t_   16
  pthread_mutex_t_   28
  pthread_mutexattr_t_4
   pthread_spinlock_t_   12
pthread_barrier_t_   36
pthread_barrierattr_t_4
pthread_key_t_4
   pthread_cond_t_  108
   pthread_condattr_t_4
 pthread_rwlock_t_   32
 pthread_rwlockattr_t_4
   pthread_once_t_4
   sched_param4
---
Passed
Compiling loadfree.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o loadfree.exe loadfree.c -I./include 
-L../outlib -lwinpthread -lsupc++ -lws2_32
loadfree.c: In function 'main':
loadfree.c:61:13: warning: unused variable 'hinst' [-Wunused-variable]
Preparing loadfree TESTS
Running loadfree
./loadfree
Passed
Compiling self1.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o self1.exe self1.c -I./include 
-L../outlib -lwinpthread -lsupc++ -lws2_32
Running self1
./self1
Passed
Compiling mutex5.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o mutex5.exe mutex5.c -I./include 
-L../outlib -lwinpthread -lsupc++ -lws2_32
Running mutex5
./mutex5
Passed
Compiling mutex1.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o mutex1.exe mutex1.c -I./include 
-L../outlib -lwinpthread -lsupc++ -lws2_32
Running mutex1
./mutex1
Passed
Compiling mutex1e.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o mutex1e.exe mutex1e.c -I./include 
-L../outlib -lwinpthread -lsupc++ -lws2_32
Running mutex1e
./mutex1e
Passed
Compiling mutex1n.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o mutex1n.exe mutex1n.c -I./include 
-L../outlib -lwinpthread -lsupc++ -lws2_32
Running mutex1n
./mutex1n
Passed
Compiling mutex1r.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o mutex1r.exe mutex1r.c -I./include 
-L../outlib -lwinpthread -lsupc++ -lws2_32
Running mutex1r
./mutex1r
Passed
Compiling semaphore1.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o semaphore1.exe semaphore1.c 
-I./include -L../outlib -lwinpthread -lsupc++ -lws2_32
Running semaphore1
./semaphore1
thread: sem_trywait 1: expecting error EAGAIN: got EAGAIN
thread: ok 2
main: sem_trywait 1: expecting error EAGAIN: got EAGAIN
main: ok 2
Passed
Compiling semaphore2.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o semaphore2.exe semaphore2.c 
-I./include -L../outlib -lwinpthread -lsupc++ -lws2_32
Running semaphore2
./semaphore2
Passed
Compiling semaphore3.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o semaphore3.exe semaphore3.c 
-I./include -L../outlib -lwinpthread -lsupc++ -lws2_32
Running semaphore3
./semaphore3
Complete
Passed
Compiling condvar1.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o condvar1.exe condvar1.c -I./include 
-L../outlib -lwinpthread -lsupc++ -lws2_32
Running condvar1
./condvar1
Passed
Compiling condvar1_1.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o condvar1_1.exe condvar1_1.c 
-I./include -L../outlib -lwinpthread -lsupc++ -lws2_32
Running condvar1_1
./condvar1_1
Passed
Compiling condvar1_2.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o condvar1_2.exe condvar1_2.c 
-I./include -L../outlib -lwinpthread -lsupc++ -lws2_32
Compiling join2.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o join2.exe join2.c -I./include 
-L../outlib -lwinpthread -lsupc++ -lws2_32
Compiling create1.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o create1.exe create1.c -I./include 
-L../outlib -lwinpthread -lsupc++ -lws2_32
Compiling mutex2.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o mutex2.exe mutex2.c -I./include 
-L../outlib -lwinpthread -lsupc++ -lws2_32
Running mutex2
./mutex2
Try lock
Mutex locked
Mutex unlocked
Mutex destroyed
Passed
Running create1
./create1
Passed
Running join2
./join2
Passed
Running condvar1_2
./condvar1_2
Passed
Compiling condvar2.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o condvar2.exe condvar2.c -I./

Re: [Mingw-w64-public] winpthreads patch for pthread_getspecific()/pthread_setspecific() function for restore WIN last error code

[Antony Riakiotakis]

We also experience an issue with boost::filesystem::exists in blender. If
this fixes that it will be a blessing :).
--
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 endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads patch for pthread_getspecific()/pthread_setspecific() function for restore WIN last error code

[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.

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 endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads patch for pthread_getspecific()/pthread_setspecific() function for restore WIN last error code

[Ruben Van Boxem]

2012/7/16 niXman 

> 2012/7/16 Ozkan Sezer:
>
> > This was discussed quite some time ago and the suggested changes
> > look OK to me at first glance. As a reference, pthreads-win32 restores
> > the last error for pthread_getspecific() (but not for
> pthread_setspecific()
> > as far as I can see.)
>
> Without the restoration of the last error in pthread_setspecific(), this
> code will always throw an exception:
> boost::filesystem::exists("any non-existent file");
>
> With the following message:
> The operation completed successfully: "any non-existent file"
>

I have had similar reports for my posix threades toolchains. If this patch
fixes that, it would be much appreciated :)

Ruben


>
> Why is this happening, you can read here:
> http://forum.vingrad.ru/index.php?showtopic=353559&view=findpost&p=2499963
>
> But, this is a Russian forum.
>
>
>
> --
> Regards,
> niXman
> ___
> Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows:
> http://sourceforge.net/projects/mingwbuilds/
>
>
> --
> 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 endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
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 endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads patch for pthread_getspecific()/pthread_setspecific() function for restore WIN last error code

[niXman]

2012/7/16 Ozkan Sezer:

> This was discussed quite some time ago and the suggested changes
> look OK to me at first glance. As a reference, pthreads-win32 restores
> the last error for pthread_getspecific() (but not for pthread_setspecific()
> as far as I can see.)

Without the restoration of the last error ​​in pthread_setspecific(), this
code will always throw an exception:
boost::filesystem::exists("any non-existent file");

With the following message:
The operation completed successfully: "any non-existent file"

Why is this happening, you can read here:
http://forum.vingrad.ru/index.php?showtopic=353559&view=findpost&p=2499963

But, this is a Russian forum.



-- 
Regards,
niXman
___
Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows:
http://sourceforge.net/projects/mingwbuilds/

--
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 endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads patch for pthread_getspecific()/pthread_setspecific() function for restore WIN last error code

[Ozkan Sezer]

On Sat, Jul 14, 2012 at 12:23 PM, niXman  wrote:
> Patch in attachment.
>
> --
> Regards,
> niXman

This was discussed quite some time ago and the suggested changes
look OK to me at first glance. As a reference, pthreads-win32 restores
the last error for pthread_getspecific() (but not for pthread_setspecific()
as far as I can see.)  What do the admins think?

--
O.S.


winpthreads_lasterror.patch
Description: Binary data
--
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 endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] winpthreads patch for pthread_getspecific()/pthread_setspecific() function for restore WIN last error code

[niXman]

Patch in attachment.

-- 
Regards,
niXman
___
Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows:
http://sourceforge.net/projects/mingwbuilds/


winpthreads_lasterror.patch
Description: Binary data
--
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 endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads-api and GetLastError/SetLastError

[niXman]

2012/5/5 niXman :
> 2012/5/5 Kai Tietz:
>> Could somebody do tests if the LastError state can be really changed?
>
> About what tests there is a speech?

I suppose that not only pthread_getspecific() changes last_error.
As I already spoke earlier, winpthreads-api shan't change last_error
value because in documentation isn't present words about WINAPI
implementation.
Therefore, users of Windows won't known about it.

One more example:
#include 

struct C { ~C() {} };

int Test() {
int errval = ::GetLastError(); // errval == 0 !!!
C t;
return errval;
}

int main(int, const char**) {
::SetLastError(2);
return Test(); // 0
}

Sequentially calls is as follows:
main() -> Test() -> _Unwind_SjLj_Register() -> pthread_getspecific()
-> TlsGetValue()


-- 
Regards,
  niXman

--
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 endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads-api and GetLastError/SetLastError

[niXman]

2012/5/5 Kai Tietz:
> Could somebody do tests if the LastError state can be really changed?

About what tests there is a speech?


-- 
Regards,
  niXman

--
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 endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads-api and GetLastError/SetLastError

[Kai Tietz]

2012/5/5 Ozkan Sezer :
> On 5/4/12, niXman  wrote:
>> Hi,
>>
>> This simple code change the last error which sometimes is not allowed:
>>> #include 
>>> int main() {
>>>      SetLastError(33);
>>>      pthread_getspecific(0);
>>>      return GetLastError();
>>> }
>>>
>>> $ gcc test.c -otest
>>> $ ./test; echo $?
>>> $ 0
>>
>> Tell me please, have anyone faced with this problem? Maybe in the
>> mailing list there is a subject about this?
>> The question is whether will be correct the changing of
>> winpthreads-api this way?:
>>> void* pthread_getspecific(pthread_key_t key) {
>>>    DWORD _last_error=GetLastError();
>>>    ...
>>>    ...some code...
>>>    ...
>>>    SetLastError(_last_error);
>>> }
>>
>> Indeed, logically, the implementation of winpthreads should not have
>> no effect on GetLastError/SetLastError?
>>
>
> Such preservation is indeed present in pthreads-w32 version of
> pthread_getspecific(), so should we add the following:
>
> --- thread.c~
> +++ thread.c
> @@ -748,10 +748,12 @@ void *
>  pthread_getspecific (pthread_key_t key)
>  {
>   void *r;
> +  DWORD lasterror = GetLastError ();
>   _pthread_v *t = __pthread_self_lite ();
>   _spin_lite_lock (&t->spin_keys);
>   r = (key >= t->keymax || t->keyval_set[key] == 0 ? NULL : t->keyval[key]);
>   _spin_lite_unlock (&t->spin_keys);
> +  SetLastError (lasterror);
>   return r;
>  }
>
>
> Kai?
>
>
>> Thanks!
>>
>>
>> --
>> Regards,
>>   niXman
>
> --
> O.S.

Hmm, maybe.  In general there shouldn't be any LastError modifying
action, but maybe Sleep call can be reached, which might clobbers
status here.

Could somebody do tests if the LastError state can be really changed?

Cheers,
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 endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads-api and GetLastError/SetLastError

[Ozkan Sezer]

On 5/4/12, niXman  wrote:
> Hi,
>
> This simple code change the last error which sometimes is not allowed:
>> #include 
>> int main() {
>>  SetLastError(33);
>>  pthread_getspecific(0);
>>  return GetLastError();
>> }
>>
>> $ gcc test.c -otest
>> $ ./test; echo $?
>> $ 0
>
> Tell me please, have anyone faced with this problem? Maybe in the
> mailing list there is a subject about this?
> The question is whether will be correct the changing of
> winpthreads-api this way?:
>> void* pthread_getspecific(pthread_key_t key) {
>>DWORD _last_error=GetLastError();
>>...
>>...some code...
>>...
>>SetLastError(_last_error);
>> }
>
> Indeed, logically, the implementation of winpthreads should not have
> no effect on GetLastError/SetLastError?
>

Such preservation is indeed present in pthreads-w32 version of
pthread_getspecific(), so should we add the following:

--- thread.c~
+++ thread.c
@@ -748,10 +748,12 @@ void *
 pthread_getspecific (pthread_key_t key)
 {
   void *r;
+  DWORD lasterror = GetLastError ();
   _pthread_v *t = __pthread_self_lite ();
   _spin_lite_lock (&t->spin_keys);
   r = (key >= t->keymax || t->keyval_set[key] == 0 ? NULL : t->keyval[key]);
   _spin_lite_unlock (&t->spin_keys);
+  SetLastError (lasterror);
   return r;
 }


Kai?


> Thanks!
>
>
> --
> Regards,
>   niXman

--
O.S.

--
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 endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] winpthreads-api and GetLastError/SetLastError

[niXman]

Hi,

This simple code change the last error which sometimes is not allowed:
> #include 
> int main() {
>   SetLastError(33);
>   pthread_getspecific(0);
>   return GetLastError();
> }
>
> $ gcc test.c -otest
> $ ./test; echo $?
> $ 0

Tell me please, have anyone faced with this problem? Maybe in the
mailing list there is a subject about this?
The question is whether will be correct the changing of
winpthreads-api this way?:
> void* pthread_getspecific(pthread_key_t key) {
>DWORD _last_error=GetLastError();
>...
>...some code...
>...
>SetLastError(_last_error);
> }

Indeed, logically, the implementation of winpthreads should not have
no effect on GetLastError/SetLastError?

Thanks!


-- 
Regards,
  niXman

--
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 endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[Ozkan Sezer]

>> Look sched.h and semaphore.h headers. They both are defined macros to
>> export. I offered the same patch.
>> What my patch does not suit you?
>>
>
> First, I said that I left that patch to others to review and decide.
>
> Second, and more importantly, I must understand why it does not work
> with you: Are you sure that you patched the time.h in your toolchain
> installation? And, since you didn't send the preprocessed sources, I
> still don't know what is going on on your end.
 Yesterday I sent a email with an attachment. I do not know why it was
 not delivered.
>>

It was delivered and I made the time.h patch using the information
from it. However I need a new one: preprocessed sources after you
did the following:
- applied the time.h patch to time.h in your toolchain installation
- did a make distclean in winpthreads
- reconfigured it and rebuilt it

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[Kai Tietz]

2012/1/18 niXman :
> 2012/1/18 Kai Tietz :
>> 2012/1/18 niXman :
>>> 2012/1/18 Ozkan Sezer :
 On Wed, Jan 18, 2012 at 9:14 AM, niXman  wrote:
> Look sched.h and semaphore.h headers. They both are defined macros to
> export. I offered the same patch.
> What my patch does not suit you?
>

 First, I said that I left that patch to others to review and decide.

 Second, and more importantly, I must understand why it does not work
 with you: Are you sure that you patched the time.h in your toolchain
 installation? And, since you didn't send the preprocessed sources, I
 still don't know what is going on on your end.
>>> Yesterday I sent a email with an attachment. I do not know why it was
>>> not delivered.
>>
>> I can tell you, and you should have received a reply by ML that your
>> mail exceeds size-limit.  Maybe pack attachment as gz/bz/zip to reduce
>> it size.  It is really no fun to have 305 Kb attachments in ML.
> I pack it with 7z.
>
> niXman.

I just checked ML and there is no message pending by you.

Kai

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[niXman]

2012/1/18 Kai Tietz :
> 2012/1/18 niXman :
>> 2012/1/18 Ozkan Sezer :
>>> On Wed, Jan 18, 2012 at 9:14 AM, niXman  wrote:
 Look sched.h and semaphore.h headers. They both are defined macros to
 export. I offered the same patch.
 What my patch does not suit you?

>>>
>>> First, I said that I left that patch to others to review and decide.
>>>
>>> Second, and more importantly, I must understand why it does not work
>>> with you: Are you sure that you patched the time.h in your toolchain
>>> installation? And, since you didn't send the preprocessed sources, I
>>> still don't know what is going on on your end.
>> Yesterday I sent a email with an attachment. I do not know why it was
>> not delivered.
>
> I can tell you, and you should have received a reply by ML that your
> mail exceeds size-limit.  Maybe pack attachment as gz/bz/zip to reduce
> it size.  It is really no fun to have 305 Kb attachments in ML.
I pack it with 7z.

niXman.


>
> Regards,
> Kai
>
> --
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[Kai Tietz]

2012/1/18 niXman :
> 2012/1/18 Ozkan Sezer :
>> On Wed, Jan 18, 2012 at 9:14 AM, niXman  wrote:
>>> Look sched.h and semaphore.h headers. They both are defined macros to
>>> export. I offered the same patch.
>>> What my patch does not suit you?
>>>
>>
>> First, I said that I left that patch to others to review and decide.
>>
>> Second, and more importantly, I must understand why it does not work
>> with you: Are you sure that you patched the time.h in your toolchain
>> installation? And, since you didn't send the preprocessed sources, I
>> still don't know what is going on on your end.
> Yesterday I sent a email with an attachment. I do not know why it was
> not delivered.

I can tell you, and you should have received a reply by ML that your
mail exceeds size-limit.  Maybe pack attachment as gz/bz/zip to reduce
it size.  It is really no fun to have 305 Kb attachments in ML.

Regards,
Kai

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[niXman]

2012/1/18 Ozkan Sezer :
> On Wed, Jan 18, 2012 at 9:14 AM, niXman  wrote:
>> Look sched.h and semaphore.h headers. They both are defined macros to
>> export. I offered the same patch.
>> What my patch does not suit you?
>>
>
> First, I said that I left that patch to others to review and decide.
>
> Second, and more importantly, I must understand why it does not work
> with you: Are you sure that you patched the time.h in your toolchain
> installation? And, since you didn't send the preprocessed sources, I
> still don't know what is going on on your end.
Yesterday I sent a email with an attachment. I do not know why it was
not delivered.


>
> --
> O.S.
>
> --
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[Ozkan Sezer]

On Wed, Jan 18, 2012 at 9:14 AM, niXman  wrote:
> Look sched.h and semaphore.h headers. They both are defined macros to
> export. I offered the same patch.
> What my patch does not suit you?
>

First, I said that I left that patch to others to review and decide.

Second, and more importantly, I must understand why it does not work
with you: Are you sure that you patched the time.h in your toolchain
installation? And, since you didn't send the preprocessed sources, I
still don't know what is going on on your end.

--
O.S.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[niXman]

Look sched.h and semaphore.h headers. They both are defined macros to
export. I offered the same patch.
What my patch does not suit you?

2012/1/18 Ozkan Sezer :
> On Wed, Jan 18, 2012 at 8:05 AM, niXman  wrote:
>> 2012/1/17 Ozkan Sezer :
>>> On Tue, Jan 17, 2012 at 1:24 PM, niXman  wrote:
 2012/1/17 Ozkan Sezer :
> On Tue, Jan 17, 2012 at 12:49 PM, niXman  wrote:
>> Hi Ozkan.
>>
>> I checked out your patch. But the problem remained. clock_ * functions
>> are not exported.
>> I attach a patch. Check it out please.
>>
>> niXman.
>
> Note that wihpthreads is at rev.4718 in the svn: make sure that you
> are using the latest.  With rev. 4718, I compiled for both x86 and
> for x86_64, I always saw the clock* functions in the dll.
 Yes, this revision and I'm using. Downloaded an hour ago.


>
> Not making a comment on your patch for the moment, (other, please
> take a look at it if you can), however, I do wonder how the preprocessed
> sources (-save-temps) look like when you are compiling winpthreads:
> can you please provide that information?
 Attached.

>>>
>>> OK, this is because of the oh-so-wonderful-and-so-great idea
>>> of including pthread_time.h from within time.h, and you obviously
>>> have pthread_time.h among the system headers.
>>>
>>> Does the attached patch help?
>> No. The problem are still not solved.
>>
>> niXman.
>>
>
> Then I am out of ideas, however I must see the preprocessed
> sources again, the ones from the build with the time.h change
> applied
>
>>
>>>
>>> Kai, Jon:  OK to apply?
>>>
>>> --- time.h~
>>> +++ time.h
>>> @@ -279,8 +279,9 @@
>>>  /* POSIX 2008 says clock_gettime and timespec are defined in time.h header,
>>>    but other systems - like Linux, Solaris, etc - tend to declare such
>>>    recent extensions only if the following guards are met.  */
>>> -#if (!defined(_STRICT_STDC) && !defined(__XOPEN_OR_POSIX)) || \
>>> -       (_POSIX_C_SOURCE > 2) || defined(__EXTENSIONS__)
>>> +#if !defined(IN_WINPTHREAD) && \
>>> +       ((!defined(_STRICT_STDC) && !defined(__XOPEN_OR_POSIX)) || \
>>> +        (_POSIX_C_SOURCE > 2) || defined(__EXTENSIONS__))
>>>  #include 
>>>  #endif
>>>
>>> --
>>> O.S.
>>>
>>
>
> --
> O.S.
>
> --
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[Ozkan Sezer]

On Wed, Jan 18, 2012 at 8:05 AM, niXman  wrote:
> 2012/1/17 Ozkan Sezer :
>> On Tue, Jan 17, 2012 at 1:24 PM, niXman  wrote:
>>> 2012/1/17 Ozkan Sezer :
 On Tue, Jan 17, 2012 at 12:49 PM, niXman  wrote:
> Hi Ozkan.
>
> I checked out your patch. But the problem remained. clock_ * functions
> are not exported.
> I attach a patch. Check it out please.
>
> niXman.

 Note that wihpthreads is at rev.4718 in the svn: make sure that you
 are using the latest.  With rev. 4718, I compiled for both x86 and
 for x86_64, I always saw the clock* functions in the dll.
>>> Yes, this revision and I'm using. Downloaded an hour ago.
>>>
>>>

 Not making a comment on your patch for the moment, (other, please
 take a look at it if you can), however, I do wonder how the preprocessed
 sources (-save-temps) look like when you are compiling winpthreads:
 can you please provide that information?
>>> Attached.
>>>
>>
>> OK, this is because of the oh-so-wonderful-and-so-great idea
>> of including pthread_time.h from within time.h, and you obviously
>> have pthread_time.h among the system headers.
>>
>> Does the attached patch help?
> No. The problem are still not solved.
>
> niXman.
>

Then I am out of ideas, however I must see the preprocessed
sources again, the ones from the build with the time.h change
applied

>
>>
>> Kai, Jon:  OK to apply?
>>
>> --- time.h~
>> +++ time.h
>> @@ -279,8 +279,9 @@
>>  /* POSIX 2008 says clock_gettime and timespec are defined in time.h header,
>>    but other systems - like Linux, Solaris, etc - tend to declare such
>>    recent extensions only if the following guards are met.  */
>> -#if (!defined(_STRICT_STDC) && !defined(__XOPEN_OR_POSIX)) || \
>> -       (_POSIX_C_SOURCE > 2) || defined(__EXTENSIONS__)
>> +#if !defined(IN_WINPTHREAD) && \
>> +       ((!defined(_STRICT_STDC) && !defined(__XOPEN_OR_POSIX)) || \
>> +        (_POSIX_C_SOURCE > 2) || defined(__EXTENSIONS__))
>>  #include 
>>  #endif
>>
>> --
>> O.S.
>>
>

--
O.S.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[niXman]

2012/1/17 Ozkan Sezer :
> On Tue, Jan 17, 2012 at 1:24 PM, niXman  wrote:
>> 2012/1/17 Ozkan Sezer :
>>> On Tue, Jan 17, 2012 at 12:49 PM, niXman  wrote:
 Hi Ozkan.

 I checked out your patch. But the problem remained. clock_ * functions
 are not exported.
 I attach a patch. Check it out please.

 niXman.
>>>
>>> Note that wihpthreads is at rev.4718 in the svn: make sure that you
>>> are using the latest.  With rev. 4718, I compiled for both x86 and
>>> for x86_64, I always saw the clock* functions in the dll.
>> Yes, this revision and I'm using. Downloaded an hour ago.
>>
>>
>>>
>>> Not making a comment on your patch for the moment, (other, please
>>> take a look at it if you can), however, I do wonder how the preprocessed
>>> sources (-save-temps) look like when you are compiling winpthreads:
>>> can you please provide that information?
>> Attached.
>>
>
> OK, this is because of the oh-so-wonderful-and-so-great idea
> of including pthread_time.h from within time.h, and you obviously
> have pthread_time.h among the system headers.
>
> Does the attached patch help?
No. The problem are still not solved.

niXman.


>
> Kai, Jon:  OK to apply?
>
> --- time.h~
> +++ time.h
> @@ -279,8 +279,9 @@
>  /* POSIX 2008 says clock_gettime and timespec are defined in time.h header,
>    but other systems - like Linux, Solaris, etc - tend to declare such
>    recent extensions only if the following guards are met.  */
> -#if (!defined(_STRICT_STDC) && !defined(__XOPEN_OR_POSIX)) || \
> -       (_POSIX_C_SOURCE > 2) || defined(__EXTENSIONS__)
> +#if !defined(IN_WINPTHREAD) && \
> +       ((!defined(_STRICT_STDC) && !defined(__XOPEN_OR_POSIX)) || \
> +        (_POSIX_C_SOURCE > 2) || defined(__EXTENSIONS__))
>  #include 
>  #endif
>
> --
> O.S.
>
> --
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[Ozkan Sezer]

On Tue, Jan 17, 2012 at 2:22 PM, Kai Tietz  wrote:
> 2012/1/17 Ozkan Sezer :
>> On Tue, Jan 17, 2012 at 1:24 PM, niXman  wrote:
>>> 2012/1/17 Ozkan Sezer :
 On Tue, Jan 17, 2012 at 12:49 PM, niXman  wrote:
> Hi Ozkan.
>
> I checked out your patch. But the problem remained. clock_ * functions
> are not exported.
> I attach a patch. Check it out please.
>
> niXman.

 Note that wihpthreads is at rev.4718 in the svn: make sure that you
 are using the latest.  With rev. 4718, I compiled for both x86 and
 for x86_64, I always saw the clock* functions in the dll.
>>> Yes, this revision and I'm using. Downloaded an hour ago.
>>>
>>>

 Not making a comment on your patch for the moment, (other, please
 take a look at it if you can), however, I do wonder how the preprocessed
 sources (-save-temps) look like when you are compiling winpthreads:
 can you please provide that information?
>>> Attached.
>>>
>>
>> OK, this is because of the oh-so-wonderful-and-so-great idea
>> of including pthread_time.h from within time.h, and you obviously
>> have pthread_time.h among the system headers.
>>
>> Does the attached patch help?
>>
>> Kai, Jon:  OK to apply?
>>
>> --- time.h~
>> +++ time.h
>> @@ -279,8 +279,9 @@
>>  /* POSIX 2008 says clock_gettime and timespec are defined in time.h header,
>>    but other systems - like Linux, Solaris, etc - tend to declare such
>>    recent extensions only if the following guards are met.  */
>> -#if (!defined(_STRICT_STDC) && !defined(__XOPEN_OR_POSIX)) || \
>> -       (_POSIX_C_SOURCE > 2) || defined(__EXTENSIONS__)
>> +#if !defined(IN_WINPTHREAD) && \
>> +       ((!defined(_STRICT_STDC) && !defined(__XOPEN_OR_POSIX)) || \
>> +        (_POSIX_C_SOURCE > 2) || defined(__EXTENSIONS__))
>>  #include 
>>  #endif
>>
>> --
>> O.S.
>
> Ah, that's the cause. Grr, yes patch is ok.

Applied to v2.x at rev. 4740, to trunk at rev. 4741.

>   But maybe we should use
> here for winpthread instead absolute includes (via #include
> "../include/...") to avoid that system-header is choosen.
>

No, the issue is not about picking the wrong header, it is
about the include order: time.h gets included before pthread.h
therefore the declspec directives weren't defined correctly for
the clock functions.

> Kai
>

--
O.S.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[Kai Tietz]

2012/1/17 Ozkan Sezer :
> On Tue, Jan 17, 2012 at 1:24 PM, niXman  wrote:
>> 2012/1/17 Ozkan Sezer :
>>> On Tue, Jan 17, 2012 at 12:49 PM, niXman  wrote:
 Hi Ozkan.

 I checked out your patch. But the problem remained. clock_ * functions
 are not exported.
 I attach a patch. Check it out please.

 niXman.
>>>
>>> Note that wihpthreads is at rev.4718 in the svn: make sure that you
>>> are using the latest.  With rev. 4718, I compiled for both x86 and
>>> for x86_64, I always saw the clock* functions in the dll.
>> Yes, this revision and I'm using. Downloaded an hour ago.
>>
>>
>>>
>>> Not making a comment on your patch for the moment, (other, please
>>> take a look at it if you can), however, I do wonder how the preprocessed
>>> sources (-save-temps) look like when you are compiling winpthreads:
>>> can you please provide that information?
>> Attached.
>>
>
> OK, this is because of the oh-so-wonderful-and-so-great idea
> of including pthread_time.h from within time.h, and you obviously
> have pthread_time.h among the system headers.
>
> Does the attached patch help?
>
> Kai, Jon:  OK to apply?
>
> --- time.h~
> +++ time.h
> @@ -279,8 +279,9 @@
>  /* POSIX 2008 says clock_gettime and timespec are defined in time.h header,
>    but other systems - like Linux, Solaris, etc - tend to declare such
>    recent extensions only if the following guards are met.  */
> -#if (!defined(_STRICT_STDC) && !defined(__XOPEN_OR_POSIX)) || \
> -       (_POSIX_C_SOURCE > 2) || defined(__EXTENSIONS__)
> +#if !defined(IN_WINPTHREAD) && \
> +       ((!defined(_STRICT_STDC) && !defined(__XOPEN_OR_POSIX)) || \
> +        (_POSIX_C_SOURCE > 2) || defined(__EXTENSIONS__))
>  #include 
>  #endif
>
> --
> O.S.

Ah, that's the cause. Grr, yes patch is ok.  But maybe we should use
here for winpthread instead absolute includes (via #include
"../include/...") to avoid that system-header is choosen.

Kai

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[Ozkan Sezer]

On Tue, Jan 17, 2012 at 1:24 PM, niXman  wrote:
> 2012/1/17 Ozkan Sezer :
>> On Tue, Jan 17, 2012 at 12:49 PM, niXman  wrote:
>>> Hi Ozkan.
>>>
>>> I checked out your patch. But the problem remained. clock_ * functions
>>> are not exported.
>>> I attach a patch. Check it out please.
>>>
>>> niXman.
>>
>> Note that wihpthreads is at rev.4718 in the svn: make sure that you
>> are using the latest.  With rev. 4718, I compiled for both x86 and
>> for x86_64, I always saw the clock* functions in the dll.
> Yes, this revision and I'm using. Downloaded an hour ago.
>
>
>>
>> Not making a comment on your patch for the moment, (other, please
>> take a look at it if you can), however, I do wonder how the preprocessed
>> sources (-save-temps) look like when you are compiling winpthreads:
>> can you please provide that information?
> Attached.
>

OK, this is because of the oh-so-wonderful-and-so-great idea
of including pthread_time.h from within time.h, and you obviously
have pthread_time.h among the system headers.

Does the attached patch help?

Kai, Jon:  OK to apply?

--- time.h~
+++ time.h
@@ -279,8 +279,9 @@
 /* POSIX 2008 says clock_gettime and timespec are defined in time.h header,
but other systems - like Linux, Solaris, etc - tend to declare such
recent extensions only if the following guards are met.  */
-#if (!defined(_STRICT_STDC) && !defined(__XOPEN_OR_POSIX)) || \
-   (_POSIX_C_SOURCE > 2) || defined(__EXTENSIONS__)
+#if !defined(IN_WINPTHREAD) && \
+   ((!defined(_STRICT_STDC) && !defined(__XOPEN_OR_POSIX)) || \
+(_POSIX_C_SOURCE > 2) || defined(__EXTENSIONS__))
 #include 
 #endif

--
O.S.


time.diff
Description: Binary data
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[Ozkan Sezer]

On Tue, Jan 17, 2012 at 12:49 PM, niXman  wrote:
> Hi Ozkan.
>
> I checked out your patch. But the problem remained. clock_ * functions
> are not exported.
> I attach a patch. Check it out please.
>
> niXman.

Note that wihpthreads is at rev.4718 in the svn: make sure that you
are using the latest.  With rev. 4718, I compiled for both x86 and
for x86_64, I always saw the clock* functions in the dll.

Not making a comment on your patch for the moment, (other, please
take a look at it if you can), however, I do wonder how the preprocessed
sources (-save-temps) look like when you are compiling winpthreads:
can you please provide that information?

--
O.S.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[niXman]

Hi Ozkan.

I checked out your patch. But the problem remained. clock_ * functions
are not exported.
I attach a patch. Check it out please.

niXman.


2012/1/4 Ozkan Sezer :
> On Wed, Jan 4, 2012 at 6:32 PM, niXman  wrote:
>> No, I have not tested your patch.
>> I only agreed that your patch is easier, and suggested that you check it.
>>
>
> Well then, next time I will strive to understand hidden meanings in
> other people's text
>
> At any rate,  I applied the attached minor patch to compile it (the
> makefile CFLAGS parts of it is to reduce the preprocessed source size)
> was able to compile it and the resulting dll seems to have the clock.c
> functions.
>
> Do "test" this time, please.
>
>
>> 2012/1/4 Ozkan Sezer :
>>> On Wed, Jan 4, 2012 at 4:58 PM, Ruben Van Boxem
>>>  wrote:
 2012/1/4 niXman 
>
> Hi Ozkan.
>
> I test the winpthread(rev 4706) with you patch. But clock_* functions
> also not exported.

>>>
>>> I don't have the earlier mails from this thread, but I remember
>>> that you reported success with the patch only after that I applied
>>> it.  How did it succeed that time and now it doesn't?
>>>

 I saw the same behavior yesterday. The dll does not contain the
 clock_gettime and nanosleep. The static lib does.

 I'm starting to think this might be causing the libstdc++ dll exception
 issue (due to configure failing to link these). Might be me rambling, but
 hey, I'll test it anyways once this is fixed.

 Ruben

>
>
> 2011/12/28 Ozkan Sezer :
> > On Wed, Dec 28, 2011 at 1:02 PM, niXman  wrote:
> >> Patch is attached.
> >> May be useful.
> >>
> >> 2011/12/28 niXman :
> >>> If I move declarations of clock_* functions from pthread_time.h to
> >>> pthread.h then the problem is solved.
> >>> But I am not sure that it's right.
> >>>
> >
> > Does the following one-liner fix it?
> >
> > Index: src/clock.c
> > ===
> > --- src/clock.c (revision 4705)
> > +++ src/clock.c (working copy)
> > @@ -10,6 +10,7 @@
> >  #include 
> >
> >  #include "pthread.h"
> > +#include "pthread_time.h"
> >
> >  #define POW10_7                 1000
> >  #define POW10_9                 10
> >
> >
> >
> >
> >>>
> >>> 2011/12/28 JonY :
>  On 12/28/2011 07:15, niXman wrote:
> > Hello list.
> >
> > I built the winpthreads and detected that libwinpthread-1.dll does
> > not
> > export the clock_* functions.
> >
> > __pth_gpointer_locked
> > __pthread_clock_nanosleep
> > _pthread_cleanup_dest
> > _pthread_get_state
> > _pthread_invoke_cancel
> > _pthread_key_dest
> > _pthread_rel_time_in_ms
> > _pthread_set_state
> > _pthread_time_in_ms
> > _pthread_time_in_ms_from_timespec
> > _pthread_tryjoin
> > pthread_attr_destroy
> > pthread_attr_getdetachstate
> > pthread_attr_getinheritsched
> > pthread_attr_getschedparam
> > pthread_attr_getscope
> > pthread_attr_getstackaddr
> > pthread_attr_getstacksize
> > pthread_attr_init
> > pthread_attr_setdetachstate
> > pthread_attr_setinheritsched
> > pthread_attr_setschedparam
> > pthread_attr_setscope
> > pthread_attr_setstackaddr
> > pthread_attr_setstacksize
> > pthread_barrier_destroy
> > pthread_barrier_init
> > pthread_barrier_wait
> > pthread_barrierattr_destroy
> > pthread_barrierattr_getpshared
> > pthread_barrierattr_init
> > pthread_barrierattr_setpshared
> > pthread_cancel
> > pthread_cond_broadcast
> > pthread_cond_destroy
> > pthread_cond_init
> > pthread_cond_signal
> > pthread_cond_timedwait
> > pthread_cond_wait
> > pthread_condattr_destroy
> > pthread_condattr_getclock
> > pthread_condattr_getpshared
> > pthread_condattr_init
> > pthread_condattr_setclock
> > pthread_condattr_setpshared
> > pthread_create
> > pthread_create_wrapper
> > pthread_delay_np
> > pthread_detach
> > pthread_equal
> > pthread_exit
> > pthread_get_concurrency
> > pthread_getclean
> > pthread_getconcurrency
> > pthread_getevent
> > pthread_gethandle
> > pthread_getschedparam
> > pthread_getspecific
> > pthread_join
> > pthread_key_create
> > pthread_key_delete
> > pthread_kill
> > pthread_mutex_destroy
> > pthread_mutex_init
> > pthread_mutex_lock
> > pthread_mutex_timedlock
> > pthread_mutex_trylock
> > pthread_mutex_unlock
> > pthread_mutexa

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[Ozkan Sezer]

On Wed, Jan 4, 2012 at 6:32 PM, niXman  wrote:
> No, I have not tested your patch.
> I only agreed that your patch is easier, and suggested that you check it.
>

Well then, next time I will strive to understand hidden meanings in
other people's text

At any rate,  I applied the attached minor patch to compile it (the
makefile CFLAGS parts of it is to reduce the preprocessed source size)
was able to compile it and the resulting dll seems to have the clock.c
functions.

Do "test" this time, please.


> 2012/1/4 Ozkan Sezer :
>> On Wed, Jan 4, 2012 at 4:58 PM, Ruben Van Boxem
>>  wrote:
>>> 2012/1/4 niXman 

 Hi Ozkan.

 I test the winpthread(rev 4706) with you patch. But clock_* functions
 also not exported.
>>>
>>
>> I don't have the earlier mails from this thread, but I remember
>> that you reported success with the patch only after that I applied
>> it.  How did it succeed that time and now it doesn't?
>>
>>>
>>> I saw the same behavior yesterday. The dll does not contain the
>>> clock_gettime and nanosleep. The static lib does.
>>>
>>> I'm starting to think this might be causing the libstdc++ dll exception
>>> issue (due to configure failing to link these). Might be me rambling, but
>>> hey, I'll test it anyways once this is fixed.
>>>
>>> Ruben
>>>


 2011/12/28 Ozkan Sezer :
 > On Wed, Dec 28, 2011 at 1:02 PM, niXman  wrote:
 >> Patch is attached.
 >> May be useful.
 >>
 >> 2011/12/28 niXman :
 >>> If I move declarations of clock_* functions from pthread_time.h to
 >>> pthread.h then the problem is solved.
 >>> But I am not sure that it's right.
 >>>
 >
 > Does the following one-liner fix it?
 >
 > Index: src/clock.c
 > ===
 > --- src/clock.c (revision 4705)
 > +++ src/clock.c (working copy)
 > @@ -10,6 +10,7 @@
 >  #include 
 >
 >  #include "pthread.h"
 > +#include "pthread_time.h"
 >
 >  #define POW10_7                 1000
 >  #define POW10_9                 10
 >
 >
 >
 >
 >>>
 >>> 2011/12/28 JonY :
  On 12/28/2011 07:15, niXman wrote:
 > Hello list.
 >
 > I built the winpthreads and detected that libwinpthread-1.dll does
 > not
 > export the clock_* functions.
 >
 > __pth_gpointer_locked
 > __pthread_clock_nanosleep
 > _pthread_cleanup_dest
 > _pthread_get_state
 > _pthread_invoke_cancel
 > _pthread_key_dest
 > _pthread_rel_time_in_ms
 > _pthread_set_state
 > _pthread_time_in_ms
 > _pthread_time_in_ms_from_timespec
 > _pthread_tryjoin
 > pthread_attr_destroy
 > pthread_attr_getdetachstate
 > pthread_attr_getinheritsched
 > pthread_attr_getschedparam
 > pthread_attr_getscope
 > pthread_attr_getstackaddr
 > pthread_attr_getstacksize
 > pthread_attr_init
 > pthread_attr_setdetachstate
 > pthread_attr_setinheritsched
 > pthread_attr_setschedparam
 > pthread_attr_setscope
 > pthread_attr_setstackaddr
 > pthread_attr_setstacksize
 > pthread_barrier_destroy
 > pthread_barrier_init
 > pthread_barrier_wait
 > pthread_barrierattr_destroy
 > pthread_barrierattr_getpshared
 > pthread_barrierattr_init
 > pthread_barrierattr_setpshared
 > pthread_cancel
 > pthread_cond_broadcast
 > pthread_cond_destroy
 > pthread_cond_init
 > pthread_cond_signal
 > pthread_cond_timedwait
 > pthread_cond_wait
 > pthread_condattr_destroy
 > pthread_condattr_getclock
 > pthread_condattr_getpshared
 > pthread_condattr_init
 > pthread_condattr_setclock
 > pthread_condattr_setpshared
 > pthread_create
 > pthread_create_wrapper
 > pthread_delay_np
 > pthread_detach
 > pthread_equal
 > pthread_exit
 > pthread_get_concurrency
 > pthread_getclean
 > pthread_getconcurrency
 > pthread_getevent
 > pthread_gethandle
 > pthread_getschedparam
 > pthread_getspecific
 > pthread_join
 > pthread_key_create
 > pthread_key_delete
 > pthread_kill
 > pthread_mutex_destroy
 > pthread_mutex_init
 > pthread_mutex_lock
 > pthread_mutex_timedlock
 > pthread_mutex_trylock
 > pthread_mutex_unlock
 > pthread_mutexattr_destroy
 > pthread_mutexattr_getprioceiling
 > pthread_mutexattr_getprotocol
 > pthread_mutexattr_getpshared
 > pthread_mutexattr_gettype
 > pthread_mutexattr_init
 > pthread_mutexattr_setprioceiling
 > pthread_mutexattr_setprotocol
 > pthread_mutexattr_setpshare

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[niXman]

No, I have not tested your patch.
I only agreed that your patch is easier, and suggested that you check it.

2012/1/4 Ozkan Sezer :
> On Wed, Jan 4, 2012 at 4:58 PM, Ruben Van Boxem
>  wrote:
>> 2012/1/4 niXman 
>>>
>>> Hi Ozkan.
>>>
>>> I test the winpthread(rev 4706) with you patch. But clock_* functions
>>> also not exported.
>>
>
> I don't have the earlier mails from this thread, but I remember
> that you reported success with the patch only after that I applied
> it.  How did it succeed that time and now it doesn't?
>
>>
>> I saw the same behavior yesterday. The dll does not contain the
>> clock_gettime and nanosleep. The static lib does.
>>
>> I'm starting to think this might be causing the libstdc++ dll exception
>> issue (due to configure failing to link these). Might be me rambling, but
>> hey, I'll test it anyways once this is fixed.
>>
>> Ruben
>>
>>>
>>>
>>> 2011/12/28 Ozkan Sezer :
>>> > On Wed, Dec 28, 2011 at 1:02 PM, niXman  wrote:
>>> >> Patch is attached.
>>> >> May be useful.
>>> >>
>>> >> 2011/12/28 niXman :
>>> >>> If I move declarations of clock_* functions from pthread_time.h to
>>> >>> pthread.h then the problem is solved.
>>> >>> But I am not sure that it's right.
>>> >>>
>>> >
>>> > Does the following one-liner fix it?
>>> >
>>> > Index: src/clock.c
>>> > ===
>>> > --- src/clock.c (revision 4705)
>>> > +++ src/clock.c (working copy)
>>> > @@ -10,6 +10,7 @@
>>> >  #include 
>>> >
>>> >  #include "pthread.h"
>>> > +#include "pthread_time.h"
>>> >
>>> >  #define POW10_7                 1000
>>> >  #define POW10_9                 10
>>> >
>>> >
>>> >
>>> >
>>> >>>
>>> >>> 2011/12/28 JonY :
>>>  On 12/28/2011 07:15, niXman wrote:
>>> > Hello list.
>>> >
>>> > I built the winpthreads and detected that libwinpthread-1.dll does
>>> > not
>>> > export the clock_* functions.
>>> >
>>> > __pth_gpointer_locked
>>> > __pthread_clock_nanosleep
>>> > _pthread_cleanup_dest
>>> > _pthread_get_state
>>> > _pthread_invoke_cancel
>>> > _pthread_key_dest
>>> > _pthread_rel_time_in_ms
>>> > _pthread_set_state
>>> > _pthread_time_in_ms
>>> > _pthread_time_in_ms_from_timespec
>>> > _pthread_tryjoin
>>> > pthread_attr_destroy
>>> > pthread_attr_getdetachstate
>>> > pthread_attr_getinheritsched
>>> > pthread_attr_getschedparam
>>> > pthread_attr_getscope
>>> > pthread_attr_getstackaddr
>>> > pthread_attr_getstacksize
>>> > pthread_attr_init
>>> > pthread_attr_setdetachstate
>>> > pthread_attr_setinheritsched
>>> > pthread_attr_setschedparam
>>> > pthread_attr_setscope
>>> > pthread_attr_setstackaddr
>>> > pthread_attr_setstacksize
>>> > pthread_barrier_destroy
>>> > pthread_barrier_init
>>> > pthread_barrier_wait
>>> > pthread_barrierattr_destroy
>>> > pthread_barrierattr_getpshared
>>> > pthread_barrierattr_init
>>> > pthread_barrierattr_setpshared
>>> > pthread_cancel
>>> > pthread_cond_broadcast
>>> > pthread_cond_destroy
>>> > pthread_cond_init
>>> > pthread_cond_signal
>>> > pthread_cond_timedwait
>>> > pthread_cond_wait
>>> > pthread_condattr_destroy
>>> > pthread_condattr_getclock
>>> > pthread_condattr_getpshared
>>> > pthread_condattr_init
>>> > pthread_condattr_setclock
>>> > pthread_condattr_setpshared
>>> > pthread_create
>>> > pthread_create_wrapper
>>> > pthread_delay_np
>>> > pthread_detach
>>> > pthread_equal
>>> > pthread_exit
>>> > pthread_get_concurrency
>>> > pthread_getclean
>>> > pthread_getconcurrency
>>> > pthread_getevent
>>> > pthread_gethandle
>>> > pthread_getschedparam
>>> > pthread_getspecific
>>> > pthread_join
>>> > pthread_key_create
>>> > pthread_key_delete
>>> > pthread_kill
>>> > pthread_mutex_destroy
>>> > pthread_mutex_init
>>> > pthread_mutex_lock
>>> > pthread_mutex_timedlock
>>> > pthread_mutex_trylock
>>> > pthread_mutex_unlock
>>> > pthread_mutexattr_destroy
>>> > pthread_mutexattr_getprioceiling
>>> > pthread_mutexattr_getprotocol
>>> > pthread_mutexattr_getpshared
>>> > pthread_mutexattr_gettype
>>> > pthread_mutexattr_init
>>> > pthread_mutexattr_setprioceiling
>>> > pthread_mutexattr_setprotocol
>>> > pthread_mutexattr_setpshared
>>> > pthread_mutexattr_settype
>>> > pthread_num_processors_np
>>> > pthread_once
>>> > pthread_rwlock_destroy
>>> > pthread_rwlock_init
>>> > pthread_rwlock_rdlock
>>> > pthread_rwlock_timedrdlock
>>> > pthread_rwlock_timedwrlock
>>> > pthread_rwlock_tryrdlock
>>> > pthread_rwlock_trywrlock
>>> > pthread_rwlock_unlock
>>> > pthread_rwlock_wrlock
>>> > pthread_rwlockattr_destroy
>>> > pthread_rwlockattr_getpshared
>>> > pthread_rwlockattr_init
>>> > pthread_rwlockatt

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[Ozkan Sezer]

On Wed, Jan 4, 2012 at 4:58 PM, Ruben Van Boxem
 wrote:
> 2012/1/4 niXman 
>>
>> Hi Ozkan.
>>
>> I test the winpthread(rev 4706) with you patch. But clock_* functions
>> also not exported.
>

I don't have the earlier mails from this thread, but I remember
that you reported success with the patch only after that I applied
it.  How did it succeed that time and now it doesn't?

>
> I saw the same behavior yesterday. The dll does not contain the
> clock_gettime and nanosleep. The static lib does.
>
> I'm starting to think this might be causing the libstdc++ dll exception
> issue (due to configure failing to link these). Might be me rambling, but
> hey, I'll test it anyways once this is fixed.
>
> Ruben
>
>>
>>
>> 2011/12/28 Ozkan Sezer :
>> > On Wed, Dec 28, 2011 at 1:02 PM, niXman  wrote:
>> >> Patch is attached.
>> >> May be useful.
>> >>
>> >> 2011/12/28 niXman :
>> >>> If I move declarations of clock_* functions from pthread_time.h to
>> >>> pthread.h then the problem is solved.
>> >>> But I am not sure that it's right.
>> >>>
>> >
>> > Does the following one-liner fix it?
>> >
>> > Index: src/clock.c
>> > ===
>> > --- src/clock.c (revision 4705)
>> > +++ src/clock.c (working copy)
>> > @@ -10,6 +10,7 @@
>> >  #include 
>> >
>> >  #include "pthread.h"
>> > +#include "pthread_time.h"
>> >
>> >  #define POW10_7                 1000
>> >  #define POW10_9                 10
>> >
>> >
>> >
>> >
>> >>>
>> >>> 2011/12/28 JonY :
>>  On 12/28/2011 07:15, niXman wrote:
>> > Hello list.
>> >
>> > I built the winpthreads and detected that libwinpthread-1.dll does
>> > not
>> > export the clock_* functions.
>> >
>> > __pth_gpointer_locked
>> > __pthread_clock_nanosleep
>> > _pthread_cleanup_dest
>> > _pthread_get_state
>> > _pthread_invoke_cancel
>> > _pthread_key_dest
>> > _pthread_rel_time_in_ms
>> > _pthread_set_state
>> > _pthread_time_in_ms
>> > _pthread_time_in_ms_from_timespec
>> > _pthread_tryjoin
>> > pthread_attr_destroy
>> > pthread_attr_getdetachstate
>> > pthread_attr_getinheritsched
>> > pthread_attr_getschedparam
>> > pthread_attr_getscope
>> > pthread_attr_getstackaddr
>> > pthread_attr_getstacksize
>> > pthread_attr_init
>> > pthread_attr_setdetachstate
>> > pthread_attr_setinheritsched
>> > pthread_attr_setschedparam
>> > pthread_attr_setscope
>> > pthread_attr_setstackaddr
>> > pthread_attr_setstacksize
>> > pthread_barrier_destroy
>> > pthread_barrier_init
>> > pthread_barrier_wait
>> > pthread_barrierattr_destroy
>> > pthread_barrierattr_getpshared
>> > pthread_barrierattr_init
>> > pthread_barrierattr_setpshared
>> > pthread_cancel
>> > pthread_cond_broadcast
>> > pthread_cond_destroy
>> > pthread_cond_init
>> > pthread_cond_signal
>> > pthread_cond_timedwait
>> > pthread_cond_wait
>> > pthread_condattr_destroy
>> > pthread_condattr_getclock
>> > pthread_condattr_getpshared
>> > pthread_condattr_init
>> > pthread_condattr_setclock
>> > pthread_condattr_setpshared
>> > pthread_create
>> > pthread_create_wrapper
>> > pthread_delay_np
>> > pthread_detach
>> > pthread_equal
>> > pthread_exit
>> > pthread_get_concurrency
>> > pthread_getclean
>> > pthread_getconcurrency
>> > pthread_getevent
>> > pthread_gethandle
>> > pthread_getschedparam
>> > pthread_getspecific
>> > pthread_join
>> > pthread_key_create
>> > pthread_key_delete
>> > pthread_kill
>> > pthread_mutex_destroy
>> > pthread_mutex_init
>> > pthread_mutex_lock
>> > pthread_mutex_timedlock
>> > pthread_mutex_trylock
>> > pthread_mutex_unlock
>> > pthread_mutexattr_destroy
>> > pthread_mutexattr_getprioceiling
>> > pthread_mutexattr_getprotocol
>> > pthread_mutexattr_getpshared
>> > pthread_mutexattr_gettype
>> > pthread_mutexattr_init
>> > pthread_mutexattr_setprioceiling
>> > pthread_mutexattr_setprotocol
>> > pthread_mutexattr_setpshared
>> > pthread_mutexattr_settype
>> > pthread_num_processors_np
>> > pthread_once
>> > pthread_rwlock_destroy
>> > pthread_rwlock_init
>> > pthread_rwlock_rdlock
>> > pthread_rwlock_timedrdlock
>> > pthread_rwlock_timedwrlock
>> > pthread_rwlock_tryrdlock
>> > pthread_rwlock_trywrlock
>> > pthread_rwlock_unlock
>> > pthread_rwlock_wrlock
>> > pthread_rwlockattr_destroy
>> > pthread_rwlockattr_getpshared
>> > pthread_rwlockattr_init
>> > pthread_rwlockattr_setpshared
>> > pthread_self
>> > pthread_set_concurrency
>> > pthread_set_num_processors_np
>> > pthread_setcancelstate
>> > pthread_setcanceltype
>> > pthread_setconcurrency
>> > pthread_setschedparam
>> > pthread_setspecific
>> > pthread_spin_destroy
>>

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[Ruben Van Boxem]

2012/1/4 niXman 

> Hi Ozkan.
>
> I test the winpthread(rev 4706) with you patch. But clock_* functions
> also not exported.
>

I saw the same behavior yesterday. The dll does not contain the
clock_gettime and nanosleep. The static lib does.

I'm starting to think this might be causing the libstdc++ dll exception
issue (due to configure failing to link these). Might be me rambling, but
hey, I'll test it anyways once this is fixed.

Ruben


>
> 2011/12/28 Ozkan Sezer :
> > On Wed, Dec 28, 2011 at 1:02 PM, niXman  wrote:
> >> Patch is attached.
> >> May be useful.
> >>
> >> 2011/12/28 niXman :
> >>> If I move declarations of clock_* functions from pthread_time.h to
> >>> pthread.h then the problem is solved.
> >>> But I am not sure that it's right.
> >>>
> >
> > Does the following one-liner fix it?
> >
> > Index: src/clock.c
> > ===
> > --- src/clock.c (revision 4705)
> > +++ src/clock.c (working copy)
> > @@ -10,6 +10,7 @@
> >  #include 
> >
> >  #include "pthread.h"
> > +#include "pthread_time.h"
> >
> >  #define POW10_7 1000
> >  #define POW10_9 10
> >
> >
> >
> >
> >>>
> >>> 2011/12/28 JonY :
>  On 12/28/2011 07:15, niXman wrote:
> > Hello list.
> >
> > I built the winpthreads and detected that libwinpthread-1.dll does
> not
> > export the clock_* functions.
> >
> > __pth_gpointer_locked
> > __pthread_clock_nanosleep
> > _pthread_cleanup_dest
> > _pthread_get_state
> > _pthread_invoke_cancel
> > _pthread_key_dest
> > _pthread_rel_time_in_ms
> > _pthread_set_state
> > _pthread_time_in_ms
> > _pthread_time_in_ms_from_timespec
> > _pthread_tryjoin
> > pthread_attr_destroy
> > pthread_attr_getdetachstate
> > pthread_attr_getinheritsched
> > pthread_attr_getschedparam
> > pthread_attr_getscope
> > pthread_attr_getstackaddr
> > pthread_attr_getstacksize
> > pthread_attr_init
> > pthread_attr_setdetachstate
> > pthread_attr_setinheritsched
> > pthread_attr_setschedparam
> > pthread_attr_setscope
> > pthread_attr_setstackaddr
> > pthread_attr_setstacksize
> > pthread_barrier_destroy
> > pthread_barrier_init
> > pthread_barrier_wait
> > pthread_barrierattr_destroy
> > pthread_barrierattr_getpshared
> > pthread_barrierattr_init
> > pthread_barrierattr_setpshared
> > pthread_cancel
> > pthread_cond_broadcast
> > pthread_cond_destroy
> > pthread_cond_init
> > pthread_cond_signal
> > pthread_cond_timedwait
> > pthread_cond_wait
> > pthread_condattr_destroy
> > pthread_condattr_getclock
> > pthread_condattr_getpshared
> > pthread_condattr_init
> > pthread_condattr_setclock
> > pthread_condattr_setpshared
> > pthread_create
> > pthread_create_wrapper
> > pthread_delay_np
> > pthread_detach
> > pthread_equal
> > pthread_exit
> > pthread_get_concurrency
> > pthread_getclean
> > pthread_getconcurrency
> > pthread_getevent
> > pthread_gethandle
> > pthread_getschedparam
> > pthread_getspecific
> > pthread_join
> > pthread_key_create
> > pthread_key_delete
> > pthread_kill
> > pthread_mutex_destroy
> > pthread_mutex_init
> > pthread_mutex_lock
> > pthread_mutex_timedlock
> > pthread_mutex_trylock
> > pthread_mutex_unlock
> > pthread_mutexattr_destroy
> > pthread_mutexattr_getprioceiling
> > pthread_mutexattr_getprotocol
> > pthread_mutexattr_getpshared
> > pthread_mutexattr_gettype
> > pthread_mutexattr_init
> > pthread_mutexattr_setprioceiling
> > pthread_mutexattr_setprotocol
> > pthread_mutexattr_setpshared
> > pthread_mutexattr_settype
> > pthread_num_processors_np
> > pthread_once
> > pthread_rwlock_destroy
> > pthread_rwlock_init
> > pthread_rwlock_rdlock
> > pthread_rwlock_timedrdlock
> > pthread_rwlock_timedwrlock
> > pthread_rwlock_tryrdlock
> > pthread_rwlock_trywrlock
> > pthread_rwlock_unlock
> > pthread_rwlock_wrlock
> > pthread_rwlockattr_destroy
> > pthread_rwlockattr_getpshared
> > pthread_rwlockattr_init
> > pthread_rwlockattr_setpshared
> > pthread_self
> > pthread_set_concurrency
> > pthread_set_num_processors_np
> > pthread_setcancelstate
> > pthread_setcanceltype
> > pthread_setconcurrency
> > pthread_setschedparam
> > pthread_setspecific
> > pthread_spin_destroy
> > pthread_spin_init
> > pthread_spin_lock
> > pthread_spin_trylock
> > pthread_spin_unlock
> > pthread_testcancel
> > pthread_timechange_handler_np
> > pthread_tls_init
> > sched_get_priority_max
> > sched_get_priority_min
> > sched_getscheduler
> > sched_setscheduler
> > sched_yield
> > sem_close
> > sem_destroy
> > sem_getvalue
> > sem_init
> >

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[niXman]

Hi Ozkan.

I test the winpthread(rev 4706) with you patch. But clock_* functions
also not exported.


2011/12/28 Ozkan Sezer :
> On Wed, Dec 28, 2011 at 1:02 PM, niXman  wrote:
>> Patch is attached.
>> May be useful.
>>
>> 2011/12/28 niXman :
>>> If I move declarations of clock_* functions from pthread_time.h to
>>> pthread.h then the problem is solved.
>>> But I am not sure that it's right.
>>>
>
> Does the following one-liner fix it?
>
> Index: src/clock.c
> ===
> --- src/clock.c (revision 4705)
> +++ src/clock.c (working copy)
> @@ -10,6 +10,7 @@
>  #include 
>
>  #include "pthread.h"
> +#include "pthread_time.h"
>
>  #define POW10_7                 1000
>  #define POW10_9                 10
>
>
>
>
>>>
>>> 2011/12/28 JonY :
 On 12/28/2011 07:15, niXman wrote:
> Hello list.
>
> I built the winpthreads and detected that libwinpthread-1.dll does not
> export the clock_* functions.
>
> __pth_gpointer_locked
> __pthread_clock_nanosleep
> _pthread_cleanup_dest
> _pthread_get_state
> _pthread_invoke_cancel
> _pthread_key_dest
> _pthread_rel_time_in_ms
> _pthread_set_state
> _pthread_time_in_ms
> _pthread_time_in_ms_from_timespec
> _pthread_tryjoin
> pthread_attr_destroy
> pthread_attr_getdetachstate
> pthread_attr_getinheritsched
> pthread_attr_getschedparam
> pthread_attr_getscope
> pthread_attr_getstackaddr
> pthread_attr_getstacksize
> pthread_attr_init
> pthread_attr_setdetachstate
> pthread_attr_setinheritsched
> pthread_attr_setschedparam
> pthread_attr_setscope
> pthread_attr_setstackaddr
> pthread_attr_setstacksize
> pthread_barrier_destroy
> pthread_barrier_init
> pthread_barrier_wait
> pthread_barrierattr_destroy
> pthread_barrierattr_getpshared
> pthread_barrierattr_init
> pthread_barrierattr_setpshared
> pthread_cancel
> pthread_cond_broadcast
> pthread_cond_destroy
> pthread_cond_init
> pthread_cond_signal
> pthread_cond_timedwait
> pthread_cond_wait
> pthread_condattr_destroy
> pthread_condattr_getclock
> pthread_condattr_getpshared
> pthread_condattr_init
> pthread_condattr_setclock
> pthread_condattr_setpshared
> pthread_create
> pthread_create_wrapper
> pthread_delay_np
> pthread_detach
> pthread_equal
> pthread_exit
> pthread_get_concurrency
> pthread_getclean
> pthread_getconcurrency
> pthread_getevent
> pthread_gethandle
> pthread_getschedparam
> pthread_getspecific
> pthread_join
> pthread_key_create
> pthread_key_delete
> pthread_kill
> pthread_mutex_destroy
> pthread_mutex_init
> pthread_mutex_lock
> pthread_mutex_timedlock
> pthread_mutex_trylock
> pthread_mutex_unlock
> pthread_mutexattr_destroy
> pthread_mutexattr_getprioceiling
> pthread_mutexattr_getprotocol
> pthread_mutexattr_getpshared
> pthread_mutexattr_gettype
> pthread_mutexattr_init
> pthread_mutexattr_setprioceiling
> pthread_mutexattr_setprotocol
> pthread_mutexattr_setpshared
> pthread_mutexattr_settype
> pthread_num_processors_np
> pthread_once
> pthread_rwlock_destroy
> pthread_rwlock_init
> pthread_rwlock_rdlock
> pthread_rwlock_timedrdlock
> pthread_rwlock_timedwrlock
> pthread_rwlock_tryrdlock
> pthread_rwlock_trywrlock
> pthread_rwlock_unlock
> pthread_rwlock_wrlock
> pthread_rwlockattr_destroy
> pthread_rwlockattr_getpshared
> pthread_rwlockattr_init
> pthread_rwlockattr_setpshared
> pthread_self
> pthread_set_concurrency
> pthread_set_num_processors_np
> pthread_setcancelstate
> pthread_setcanceltype
> pthread_setconcurrency
> pthread_setschedparam
> pthread_setspecific
> pthread_spin_destroy
> pthread_spin_init
> pthread_spin_lock
> pthread_spin_trylock
> pthread_spin_unlock
> pthread_testcancel
> pthread_timechange_handler_np
> pthread_tls_init
> sched_get_priority_max
> sched_get_priority_min
> sched_getscheduler
> sched_setscheduler
> sched_yield
> sem_close
> sem_destroy
> sem_getvalue
> sem_init
> sem_open
> sem_post
> sem_post_multiple
> sem_timedwait
> sem_trywait
> sem_unlink
> sem_wait
>
> What am I doing wrongly?
>
> Regards.

 Can you check in the public pthread header? See if it has the relevant
 dllexport/dllimport attribute.



 --
 Write once. Port to many.
 Get the SDK and tools to simplify cross-platform app development. Create
 new or port existing apps to sell to consumers worldwide. Explore the
 Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
>>>

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[Ozkan Sezer]

On Wed, Dec 28, 2011 at 2:46 PM, niXman  wrote:
> yep :)
>

Applied the change to svn at rev. 4706.

> 2011/12/28 Ozkan Sezer :
>> On Wed, Dec 28, 2011 at 1:02 PM, niXman  wrote:
>>> Patch is attached.
>>> May be useful.
>>>
>>> 2011/12/28 niXman :
 If I move declarations of clock_* functions from pthread_time.h to
 pthread.h then the problem is solved.
 But I am not sure that it's right.

>>
>> Does the following one-liner fix it?
>>
>> Index: src/clock.c
>> ===
>> --- src/clock.c (revision 4705)
>> +++ src/clock.c (working copy)
>> @@ -10,6 +10,7 @@
>>  #include 
>>
>>  #include "pthread.h"
>> +#include "pthread_time.h"
>>
>>  #define POW10_7                 1000
>>  #define POW10_9                 10

--
O.S.

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[niXman]

yep :)

2011/12/28 Ozkan Sezer :
> On Wed, Dec 28, 2011 at 1:02 PM, niXman  wrote:
>> Patch is attached.
>> May be useful.
>>
>> 2011/12/28 niXman :
>>> If I move declarations of clock_* functions from pthread_time.h to
>>> pthread.h then the problem is solved.
>>> But I am not sure that it's right.
>>>
>
> Does the following one-liner fix it?
>
> Index: src/clock.c
> ===
> --- src/clock.c (revision 4705)
> +++ src/clock.c (working copy)
> @@ -10,6 +10,7 @@
>  #include 
>
>  #include "pthread.h"
> +#include "pthread_time.h"
>
>  #define POW10_7                 1000
>  #define POW10_9                 10
>
>
>
>
>>>
>>> 2011/12/28 JonY :
 On 12/28/2011 07:15, niXman wrote:
> Hello list.
>
> I built the winpthreads and detected that libwinpthread-1.dll does not
> export the clock_* functions.
>
> __pth_gpointer_locked
> __pthread_clock_nanosleep
> _pthread_cleanup_dest
> _pthread_get_state
> _pthread_invoke_cancel
> _pthread_key_dest
> _pthread_rel_time_in_ms
> _pthread_set_state
> _pthread_time_in_ms
> _pthread_time_in_ms_from_timespec
> _pthread_tryjoin
> pthread_attr_destroy
> pthread_attr_getdetachstate
> pthread_attr_getinheritsched
> pthread_attr_getschedparam
> pthread_attr_getscope
> pthread_attr_getstackaddr
> pthread_attr_getstacksize
> pthread_attr_init
> pthread_attr_setdetachstate
> pthread_attr_setinheritsched
> pthread_attr_setschedparam
> pthread_attr_setscope
> pthread_attr_setstackaddr
> pthread_attr_setstacksize
> pthread_barrier_destroy
> pthread_barrier_init
> pthread_barrier_wait
> pthread_barrierattr_destroy
> pthread_barrierattr_getpshared
> pthread_barrierattr_init
> pthread_barrierattr_setpshared
> pthread_cancel
> pthread_cond_broadcast
> pthread_cond_destroy
> pthread_cond_init
> pthread_cond_signal
> pthread_cond_timedwait
> pthread_cond_wait
> pthread_condattr_destroy
> pthread_condattr_getclock
> pthread_condattr_getpshared
> pthread_condattr_init
> pthread_condattr_setclock
> pthread_condattr_setpshared
> pthread_create
> pthread_create_wrapper
> pthread_delay_np
> pthread_detach
> pthread_equal
> pthread_exit
> pthread_get_concurrency
> pthread_getclean
> pthread_getconcurrency
> pthread_getevent
> pthread_gethandle
> pthread_getschedparam
> pthread_getspecific
> pthread_join
> pthread_key_create
> pthread_key_delete
> pthread_kill
> pthread_mutex_destroy
> pthread_mutex_init
> pthread_mutex_lock
> pthread_mutex_timedlock
> pthread_mutex_trylock
> pthread_mutex_unlock
> pthread_mutexattr_destroy
> pthread_mutexattr_getprioceiling
> pthread_mutexattr_getprotocol
> pthread_mutexattr_getpshared
> pthread_mutexattr_gettype
> pthread_mutexattr_init
> pthread_mutexattr_setprioceiling
> pthread_mutexattr_setprotocol
> pthread_mutexattr_setpshared
> pthread_mutexattr_settype
> pthread_num_processors_np
> pthread_once
> pthread_rwlock_destroy
> pthread_rwlock_init
> pthread_rwlock_rdlock
> pthread_rwlock_timedrdlock
> pthread_rwlock_timedwrlock
> pthread_rwlock_tryrdlock
> pthread_rwlock_trywrlock
> pthread_rwlock_unlock
> pthread_rwlock_wrlock
> pthread_rwlockattr_destroy
> pthread_rwlockattr_getpshared
> pthread_rwlockattr_init
> pthread_rwlockattr_setpshared
> pthread_self
> pthread_set_concurrency
> pthread_set_num_processors_np
> pthread_setcancelstate
> pthread_setcanceltype
> pthread_setconcurrency
> pthread_setschedparam
> pthread_setspecific
> pthread_spin_destroy
> pthread_spin_init
> pthread_spin_lock
> pthread_spin_trylock
> pthread_spin_unlock
> pthread_testcancel
> pthread_timechange_handler_np
> pthread_tls_init
> sched_get_priority_max
> sched_get_priority_min
> sched_getscheduler
> sched_setscheduler
> sched_yield
> sem_close
> sem_destroy
> sem_getvalue
> sem_init
> sem_open
> sem_post
> sem_post_multiple
> sem_timedwait
> sem_trywait
> sem_unlink
> sem_wait
>
> What am I doing wrongly?
>
> Regards.

 Can you check in the public pthread header? See if it has the relevant
 dllexport/dllimport attribute.



 --
 Write once. Port to many.
 Get the SDK and tools to simplify cross-platform app development. Create
 new or port existing apps to sell to consumers worldwide. Explore the
 Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
 http://p.sf.net/sfu/intel-appdev
 ___
 M

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[Ozkan Sezer]

On Wed, Dec 28, 2011 at 1:02 PM, niXman  wrote:
> Patch is attached.
> May be useful.
>
> 2011/12/28 niXman :
>> If I move declarations of clock_* functions from pthread_time.h to
>> pthread.h then the problem is solved.
>> But I am not sure that it's right.
>>

Does the following one-liner fix it?

Index: src/clock.c
===
--- src/clock.c (revision 4705)
+++ src/clock.c (working copy)
@@ -10,6 +10,7 @@
 #include 

 #include "pthread.h"
+#include "pthread_time.h"

 #define POW10_7 1000
 #define POW10_9 10




>>
>> 2011/12/28 JonY :
>>> On 12/28/2011 07:15, niXman wrote:
 Hello list.

 I built the winpthreads and detected that libwinpthread-1.dll does not
 export the clock_* functions.

 __pth_gpointer_locked
 __pthread_clock_nanosleep
 _pthread_cleanup_dest
 _pthread_get_state
 _pthread_invoke_cancel
 _pthread_key_dest
 _pthread_rel_time_in_ms
 _pthread_set_state
 _pthread_time_in_ms
 _pthread_time_in_ms_from_timespec
 _pthread_tryjoin
 pthread_attr_destroy
 pthread_attr_getdetachstate
 pthread_attr_getinheritsched
 pthread_attr_getschedparam
 pthread_attr_getscope
 pthread_attr_getstackaddr
 pthread_attr_getstacksize
 pthread_attr_init
 pthread_attr_setdetachstate
 pthread_attr_setinheritsched
 pthread_attr_setschedparam
 pthread_attr_setscope
 pthread_attr_setstackaddr
 pthread_attr_setstacksize
 pthread_barrier_destroy
 pthread_barrier_init
 pthread_barrier_wait
 pthread_barrierattr_destroy
 pthread_barrierattr_getpshared
 pthread_barrierattr_init
 pthread_barrierattr_setpshared
 pthread_cancel
 pthread_cond_broadcast
 pthread_cond_destroy
 pthread_cond_init
 pthread_cond_signal
 pthread_cond_timedwait
 pthread_cond_wait
 pthread_condattr_destroy
 pthread_condattr_getclock
 pthread_condattr_getpshared
 pthread_condattr_init
 pthread_condattr_setclock
 pthread_condattr_setpshared
 pthread_create
 pthread_create_wrapper
 pthread_delay_np
 pthread_detach
 pthread_equal
 pthread_exit
 pthread_get_concurrency
 pthread_getclean
 pthread_getconcurrency
 pthread_getevent
 pthread_gethandle
 pthread_getschedparam
 pthread_getspecific
 pthread_join
 pthread_key_create
 pthread_key_delete
 pthread_kill
 pthread_mutex_destroy
 pthread_mutex_init
 pthread_mutex_lock
 pthread_mutex_timedlock
 pthread_mutex_trylock
 pthread_mutex_unlock
 pthread_mutexattr_destroy
 pthread_mutexattr_getprioceiling
 pthread_mutexattr_getprotocol
 pthread_mutexattr_getpshared
 pthread_mutexattr_gettype
 pthread_mutexattr_init
 pthread_mutexattr_setprioceiling
 pthread_mutexattr_setprotocol
 pthread_mutexattr_setpshared
 pthread_mutexattr_settype
 pthread_num_processors_np
 pthread_once
 pthread_rwlock_destroy
 pthread_rwlock_init
 pthread_rwlock_rdlock
 pthread_rwlock_timedrdlock
 pthread_rwlock_timedwrlock
 pthread_rwlock_tryrdlock
 pthread_rwlock_trywrlock
 pthread_rwlock_unlock
 pthread_rwlock_wrlock
 pthread_rwlockattr_destroy
 pthread_rwlockattr_getpshared
 pthread_rwlockattr_init
 pthread_rwlockattr_setpshared
 pthread_self
 pthread_set_concurrency
 pthread_set_num_processors_np
 pthread_setcancelstate
 pthread_setcanceltype
 pthread_setconcurrency
 pthread_setschedparam
 pthread_setspecific
 pthread_spin_destroy
 pthread_spin_init
 pthread_spin_lock
 pthread_spin_trylock
 pthread_spin_unlock
 pthread_testcancel
 pthread_timechange_handler_np
 pthread_tls_init
 sched_get_priority_max
 sched_get_priority_min
 sched_getscheduler
 sched_setscheduler
 sched_yield
 sem_close
 sem_destroy
 sem_getvalue
 sem_init
 sem_open
 sem_post
 sem_post_multiple
 sem_timedwait
 sem_trywait
 sem_unlink
 sem_wait

 What am I doing wrongly?

 Regards.
>>>
>>> Can you check in the public pthread header? See if it has the relevant
>>> dllexport/dllimport attribute.
>>>
>>>
>>>
>>> --
>>> Write once. Port to many.
>>> Get the SDK and tools to simplify cross-platform app development. Create
>>> new or port existing apps to sell to consumers worldwide. Explore the
>>> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
>>> http://p.sf.net/sfu/intel-appdev
>>> ___
>>> Mingw-w64-public mailing list
>>> Mingw-w64-public@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>>
>
> --

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[niXman]

Patch is attached.
May be useful.

2011/12/28 niXman :
> If I move declarations of clock_* functions from pthread_time.h to
> pthread.h then the problem is solved.
> But I am not sure that it's right.
>
>
> 2011/12/28 JonY :
>> On 12/28/2011 07:15, niXman wrote:
>>> Hello list.
>>>
>>> I built the winpthreads and detected that libwinpthread-1.dll does not
>>> export the clock_* functions.
>>>
>>> __pth_gpointer_locked
>>> __pthread_clock_nanosleep
>>> _pthread_cleanup_dest
>>> _pthread_get_state
>>> _pthread_invoke_cancel
>>> _pthread_key_dest
>>> _pthread_rel_time_in_ms
>>> _pthread_set_state
>>> _pthread_time_in_ms
>>> _pthread_time_in_ms_from_timespec
>>> _pthread_tryjoin
>>> pthread_attr_destroy
>>> pthread_attr_getdetachstate
>>> pthread_attr_getinheritsched
>>> pthread_attr_getschedparam
>>> pthread_attr_getscope
>>> pthread_attr_getstackaddr
>>> pthread_attr_getstacksize
>>> pthread_attr_init
>>> pthread_attr_setdetachstate
>>> pthread_attr_setinheritsched
>>> pthread_attr_setschedparam
>>> pthread_attr_setscope
>>> pthread_attr_setstackaddr
>>> pthread_attr_setstacksize
>>> pthread_barrier_destroy
>>> pthread_barrier_init
>>> pthread_barrier_wait
>>> pthread_barrierattr_destroy
>>> pthread_barrierattr_getpshared
>>> pthread_barrierattr_init
>>> pthread_barrierattr_setpshared
>>> pthread_cancel
>>> pthread_cond_broadcast
>>> pthread_cond_destroy
>>> pthread_cond_init
>>> pthread_cond_signal
>>> pthread_cond_timedwait
>>> pthread_cond_wait
>>> pthread_condattr_destroy
>>> pthread_condattr_getclock
>>> pthread_condattr_getpshared
>>> pthread_condattr_init
>>> pthread_condattr_setclock
>>> pthread_condattr_setpshared
>>> pthread_create
>>> pthread_create_wrapper
>>> pthread_delay_np
>>> pthread_detach
>>> pthread_equal
>>> pthread_exit
>>> pthread_get_concurrency
>>> pthread_getclean
>>> pthread_getconcurrency
>>> pthread_getevent
>>> pthread_gethandle
>>> pthread_getschedparam
>>> pthread_getspecific
>>> pthread_join
>>> pthread_key_create
>>> pthread_key_delete
>>> pthread_kill
>>> pthread_mutex_destroy
>>> pthread_mutex_init
>>> pthread_mutex_lock
>>> pthread_mutex_timedlock
>>> pthread_mutex_trylock
>>> pthread_mutex_unlock
>>> pthread_mutexattr_destroy
>>> pthread_mutexattr_getprioceiling
>>> pthread_mutexattr_getprotocol
>>> pthread_mutexattr_getpshared
>>> pthread_mutexattr_gettype
>>> pthread_mutexattr_init
>>> pthread_mutexattr_setprioceiling
>>> pthread_mutexattr_setprotocol
>>> pthread_mutexattr_setpshared
>>> pthread_mutexattr_settype
>>> pthread_num_processors_np
>>> pthread_once
>>> pthread_rwlock_destroy
>>> pthread_rwlock_init
>>> pthread_rwlock_rdlock
>>> pthread_rwlock_timedrdlock
>>> pthread_rwlock_timedwrlock
>>> pthread_rwlock_tryrdlock
>>> pthread_rwlock_trywrlock
>>> pthread_rwlock_unlock
>>> pthread_rwlock_wrlock
>>> pthread_rwlockattr_destroy
>>> pthread_rwlockattr_getpshared
>>> pthread_rwlockattr_init
>>> pthread_rwlockattr_setpshared
>>> pthread_self
>>> pthread_set_concurrency
>>> pthread_set_num_processors_np
>>> pthread_setcancelstate
>>> pthread_setcanceltype
>>> pthread_setconcurrency
>>> pthread_setschedparam
>>> pthread_setspecific
>>> pthread_spin_destroy
>>> pthread_spin_init
>>> pthread_spin_lock
>>> pthread_spin_trylock
>>> pthread_spin_unlock
>>> pthread_testcancel
>>> pthread_timechange_handler_np
>>> pthread_tls_init
>>> sched_get_priority_max
>>> sched_get_priority_min
>>> sched_getscheduler
>>> sched_setscheduler
>>> sched_yield
>>> sem_close
>>> sem_destroy
>>> sem_getvalue
>>> sem_init
>>> sem_open
>>> sem_post
>>> sem_post_multiple
>>> sem_timedwait
>>> sem_trywait
>>> sem_unlink
>>> sem_wait
>>>
>>> What am I doing wrongly?
>>>
>>> Regards.
>>
>> Can you check in the public pthread header? See if it has the relevant
>> dllexport/dllimport attribute.
>>
>>
>>
>> --
>> Write once. Port to many.
>> Get the SDK and tools to simplify cross-platform app development. Create
>> new or port existing apps to sell to consumers worldwide. Explore the
>> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
>> http://p.sf.net/sfu/intel-appdev
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>


diff.patch
Description: Binary data
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[niXman]

If I move declarations of clock_* functions from pthread_time.h to
pthread.h then the problem is solved.
But I am not sure that it's right.


2011/12/28 JonY :
> On 12/28/2011 07:15, niXman wrote:
>> Hello list.
>>
>> I built the winpthreads and detected that libwinpthread-1.dll does not
>> export the clock_* functions.
>>
>> __pth_gpointer_locked
>> __pthread_clock_nanosleep
>> _pthread_cleanup_dest
>> _pthread_get_state
>> _pthread_invoke_cancel
>> _pthread_key_dest
>> _pthread_rel_time_in_ms
>> _pthread_set_state
>> _pthread_time_in_ms
>> _pthread_time_in_ms_from_timespec
>> _pthread_tryjoin
>> pthread_attr_destroy
>> pthread_attr_getdetachstate
>> pthread_attr_getinheritsched
>> pthread_attr_getschedparam
>> pthread_attr_getscope
>> pthread_attr_getstackaddr
>> pthread_attr_getstacksize
>> pthread_attr_init
>> pthread_attr_setdetachstate
>> pthread_attr_setinheritsched
>> pthread_attr_setschedparam
>> pthread_attr_setscope
>> pthread_attr_setstackaddr
>> pthread_attr_setstacksize
>> pthread_barrier_destroy
>> pthread_barrier_init
>> pthread_barrier_wait
>> pthread_barrierattr_destroy
>> pthread_barrierattr_getpshared
>> pthread_barrierattr_init
>> pthread_barrierattr_setpshared
>> pthread_cancel
>> pthread_cond_broadcast
>> pthread_cond_destroy
>> pthread_cond_init
>> pthread_cond_signal
>> pthread_cond_timedwait
>> pthread_cond_wait
>> pthread_condattr_destroy
>> pthread_condattr_getclock
>> pthread_condattr_getpshared
>> pthread_condattr_init
>> pthread_condattr_setclock
>> pthread_condattr_setpshared
>> pthread_create
>> pthread_create_wrapper
>> pthread_delay_np
>> pthread_detach
>> pthread_equal
>> pthread_exit
>> pthread_get_concurrency
>> pthread_getclean
>> pthread_getconcurrency
>> pthread_getevent
>> pthread_gethandle
>> pthread_getschedparam
>> pthread_getspecific
>> pthread_join
>> pthread_key_create
>> pthread_key_delete
>> pthread_kill
>> pthread_mutex_destroy
>> pthread_mutex_init
>> pthread_mutex_lock
>> pthread_mutex_timedlock
>> pthread_mutex_trylock
>> pthread_mutex_unlock
>> pthread_mutexattr_destroy
>> pthread_mutexattr_getprioceiling
>> pthread_mutexattr_getprotocol
>> pthread_mutexattr_getpshared
>> pthread_mutexattr_gettype
>> pthread_mutexattr_init
>> pthread_mutexattr_setprioceiling
>> pthread_mutexattr_setprotocol
>> pthread_mutexattr_setpshared
>> pthread_mutexattr_settype
>> pthread_num_processors_np
>> pthread_once
>> pthread_rwlock_destroy
>> pthread_rwlock_init
>> pthread_rwlock_rdlock
>> pthread_rwlock_timedrdlock
>> pthread_rwlock_timedwrlock
>> pthread_rwlock_tryrdlock
>> pthread_rwlock_trywrlock
>> pthread_rwlock_unlock
>> pthread_rwlock_wrlock
>> pthread_rwlockattr_destroy
>> pthread_rwlockattr_getpshared
>> pthread_rwlockattr_init
>> pthread_rwlockattr_setpshared
>> pthread_self
>> pthread_set_concurrency
>> pthread_set_num_processors_np
>> pthread_setcancelstate
>> pthread_setcanceltype
>> pthread_setconcurrency
>> pthread_setschedparam
>> pthread_setspecific
>> pthread_spin_destroy
>> pthread_spin_init
>> pthread_spin_lock
>> pthread_spin_trylock
>> pthread_spin_unlock
>> pthread_testcancel
>> pthread_timechange_handler_np
>> pthread_tls_init
>> sched_get_priority_max
>> sched_get_priority_min
>> sched_getscheduler
>> sched_setscheduler
>> sched_yield
>> sem_close
>> sem_destroy
>> sem_getvalue
>> sem_init
>> sem_open
>> sem_post
>> sem_post_multiple
>> sem_timedwait
>> sem_trywait
>> sem_unlink
>> sem_wait
>>
>> What am I doing wrongly?
>>
>> Regards.
>
> Can you check in the public pthread header? See if it has the relevant
> dllexport/dllimport attribute.
>
>
>
> --
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads doesn't export clock_* functions

[JonY]

On 12/28/2011 07:15, niXman wrote:
> Hello list.
> 
> I built the winpthreads and detected that libwinpthread-1.dll does not
> export the clock_* functions.
> 
> __pth_gpointer_locked
> __pthread_clock_nanosleep
> _pthread_cleanup_dest
> _pthread_get_state
> _pthread_invoke_cancel
> _pthread_key_dest
> _pthread_rel_time_in_ms
> _pthread_set_state
> _pthread_time_in_ms
> _pthread_time_in_ms_from_timespec
> _pthread_tryjoin
> pthread_attr_destroy
> pthread_attr_getdetachstate
> pthread_attr_getinheritsched
> pthread_attr_getschedparam
> pthread_attr_getscope
> pthread_attr_getstackaddr
> pthread_attr_getstacksize
> pthread_attr_init
> pthread_attr_setdetachstate
> pthread_attr_setinheritsched
> pthread_attr_setschedparam
> pthread_attr_setscope
> pthread_attr_setstackaddr
> pthread_attr_setstacksize
> pthread_barrier_destroy
> pthread_barrier_init
> pthread_barrier_wait
> pthread_barrierattr_destroy
> pthread_barrierattr_getpshared
> pthread_barrierattr_init
> pthread_barrierattr_setpshared
> pthread_cancel
> pthread_cond_broadcast
> pthread_cond_destroy
> pthread_cond_init
> pthread_cond_signal
> pthread_cond_timedwait
> pthread_cond_wait
> pthread_condattr_destroy
> pthread_condattr_getclock
> pthread_condattr_getpshared
> pthread_condattr_init
> pthread_condattr_setclock
> pthread_condattr_setpshared
> pthread_create
> pthread_create_wrapper
> pthread_delay_np
> pthread_detach
> pthread_equal
> pthread_exit
> pthread_get_concurrency
> pthread_getclean
> pthread_getconcurrency
> pthread_getevent
> pthread_gethandle
> pthread_getschedparam
> pthread_getspecific
> pthread_join
> pthread_key_create
> pthread_key_delete
> pthread_kill
> pthread_mutex_destroy
> pthread_mutex_init
> pthread_mutex_lock
> pthread_mutex_timedlock
> pthread_mutex_trylock
> pthread_mutex_unlock
> pthread_mutexattr_destroy
> pthread_mutexattr_getprioceiling
> pthread_mutexattr_getprotocol
> pthread_mutexattr_getpshared
> pthread_mutexattr_gettype
> pthread_mutexattr_init
> pthread_mutexattr_setprioceiling
> pthread_mutexattr_setprotocol
> pthread_mutexattr_setpshared
> pthread_mutexattr_settype
> pthread_num_processors_np
> pthread_once
> pthread_rwlock_destroy
> pthread_rwlock_init
> pthread_rwlock_rdlock
> pthread_rwlock_timedrdlock
> pthread_rwlock_timedwrlock
> pthread_rwlock_tryrdlock
> pthread_rwlock_trywrlock
> pthread_rwlock_unlock
> pthread_rwlock_wrlock
> pthread_rwlockattr_destroy
> pthread_rwlockattr_getpshared
> pthread_rwlockattr_init
> pthread_rwlockattr_setpshared
> pthread_self
> pthread_set_concurrency
> pthread_set_num_processors_np
> pthread_setcancelstate
> pthread_setcanceltype
> pthread_setconcurrency
> pthread_setschedparam
> pthread_setspecific
> pthread_spin_destroy
> pthread_spin_init
> pthread_spin_lock
> pthread_spin_trylock
> pthread_spin_unlock
> pthread_testcancel
> pthread_timechange_handler_np
> pthread_tls_init
> sched_get_priority_max
> sched_get_priority_min
> sched_getscheduler
> sched_setscheduler
> sched_yield
> sem_close
> sem_destroy
> sem_getvalue
> sem_init
> sem_open
> sem_post
> sem_post_multiple
> sem_timedwait
> sem_trywait
> sem_unlink
> sem_wait
> 
> What am I doing wrongly?
> 
> Regards.

Can you check in the public pthread header? See if it has the relevant
dllexport/dllimport attribute.




signature.asc
Description: OpenPGP digital signature
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] winpthreads doesn't export clock_* functions

[niXman]

Hello list.

I built the winpthreads and detected that libwinpthread-1.dll does not
export the clock_* functions.

__pth_gpointer_locked
__pthread_clock_nanosleep
_pthread_cleanup_dest
_pthread_get_state
_pthread_invoke_cancel
_pthread_key_dest
_pthread_rel_time_in_ms
_pthread_set_state
_pthread_time_in_ms
_pthread_time_in_ms_from_timespec
_pthread_tryjoin
pthread_attr_destroy
pthread_attr_getdetachstate
pthread_attr_getinheritsched
pthread_attr_getschedparam
pthread_attr_getscope
pthread_attr_getstackaddr
pthread_attr_getstacksize
pthread_attr_init
pthread_attr_setdetachstate
pthread_attr_setinheritsched
pthread_attr_setschedparam
pthread_attr_setscope
pthread_attr_setstackaddr
pthread_attr_setstacksize
pthread_barrier_destroy
pthread_barrier_init
pthread_barrier_wait
pthread_barrierattr_destroy
pthread_barrierattr_getpshared
pthread_barrierattr_init
pthread_barrierattr_setpshared
pthread_cancel
pthread_cond_broadcast
pthread_cond_destroy
pthread_cond_init
pthread_cond_signal
pthread_cond_timedwait
pthread_cond_wait
pthread_condattr_destroy
pthread_condattr_getclock
pthread_condattr_getpshared
pthread_condattr_init
pthread_condattr_setclock
pthread_condattr_setpshared
pthread_create
pthread_create_wrapper
pthread_delay_np
pthread_detach
pthread_equal
pthread_exit
pthread_get_concurrency
pthread_getclean
pthread_getconcurrency
pthread_getevent
pthread_gethandle
pthread_getschedparam
pthread_getspecific
pthread_join
pthread_key_create
pthread_key_delete
pthread_kill
pthread_mutex_destroy
pthread_mutex_init
pthread_mutex_lock
pthread_mutex_timedlock
pthread_mutex_trylock
pthread_mutex_unlock
pthread_mutexattr_destroy
pthread_mutexattr_getprioceiling
pthread_mutexattr_getprotocol
pthread_mutexattr_getpshared
pthread_mutexattr_gettype
pthread_mutexattr_init
pthread_mutexattr_setprioceiling
pthread_mutexattr_setprotocol
pthread_mutexattr_setpshared
pthread_mutexattr_settype
pthread_num_processors_np
pthread_once
pthread_rwlock_destroy
pthread_rwlock_init
pthread_rwlock_rdlock
pthread_rwlock_timedrdlock
pthread_rwlock_timedwrlock
pthread_rwlock_tryrdlock
pthread_rwlock_trywrlock
pthread_rwlock_unlock
pthread_rwlock_wrlock
pthread_rwlockattr_destroy
pthread_rwlockattr_getpshared
pthread_rwlockattr_init
pthread_rwlockattr_setpshared
pthread_self
pthread_set_concurrency
pthread_set_num_processors_np
pthread_setcancelstate
pthread_setcanceltype
pthread_setconcurrency
pthread_setschedparam
pthread_setspecific
pthread_spin_destroy
pthread_spin_init
pthread_spin_lock
pthread_spin_trylock
pthread_spin_unlock
pthread_testcancel
pthread_timechange_handler_np
pthread_tls_init
sched_get_priority_max
sched_get_priority_min
sched_getscheduler
sched_setscheduler
sched_yield
sem_close
sem_destroy
sem_getvalue
sem_init
sem_open
sem_post
sem_post_multiple
sem_timedwait
sem_trywait
sem_unlink
sem_wait

What am I doing wrongly?

Regards.

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads svn 4642 issue

[Ruben Van Boxem]

2011/11/30 Ozkan Sezer 

> On Wed, Nov 30, 2011 at 12:20 PM, Ruben Van Boxem
>  wrote:
> > 2011/11/29 Ozkan Sezer 
> >>
> >> On Tue, Nov 29, 2011 at 6:41 PM, Ruben Van Boxem
> >>  wrote:
> >> > 2011/11/29 xunxun 
> >> >>
> >> >> winpthreads svn 4642 add a header file called pthread_compat.h, but
> is
> >> >> missing in makefile.in when installing.
> >> >
> >> >
> >> > You are correct, I missed that.
> >> >
> >> > Could someone please commit below patch and regenerate autoshizzle
> files
> >> > (I
> >> > don't have autotools installed, nor am I on Linux)?
> >> > Index: Makefile.in
> >> > ===
> >> > --- Makefile.in (revision 4641)
> >> > +++ Makefile.in (working copy)
> >> > @@ -274,7 +274,7 @@
> >> >src/barrier.c  src/cond.c  src/misc.c  src/mutex.c  src/rwlock.c
> >> >  src/spinlock.c  src/thread.c  src/ref.c  src/sem.c  src/sched.c \
> >> >src/winpthread_internal.h  src/clock.c src/nanosleep.c
> src/version.rc
> >> >
> >> > -include_HEADERS = include/pthread.h include/sched.h
> include/semaphore.h
> >> > include/pthread_unistd.h include/pthread_time.h
> >> > +include_HEADERS = include/pthread.h include/sched.h
> include/semaphore.h
> >> > include/pthread_unistd.h include/pthread_time.h
> include/pthread_compat.h
> >> >  DISTCHECK_CONFIGURE_FLAGS = --host=$(host_triplet)
> >> >  noinst_LTLIBRARIES = libdummy.la
> >> >  libwinpthread_la_LIBADD = libdummy.la
> >> >
> >> > Thanks!
> >> >
> >> > Ruben
> >>
> >> While you are working on that, remember that you were going to
> >> fix that new header for clashes?
> >
> >
> > Yes, and here is the required changes. It still includes the makefile.in
> > bit, which needs some autotools love, which my windows box is unable to
> > give. I tested with 64-bit GCC and MSVC.
> >
> > If anyone with autotools present could please apply this patch, I and
> anyone
> > trying to use SVN HEAD would be very grateful!
> >
> > Ruben
>
> Applied your patch at rev. 4646.
>
> Also applied a patch at rev. 4647 to fix pid_t for 32 bits _MSC_VER
>

You're awesome as always, thanks!

Ruben


>
> --
> O.S.
>
>
> --
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads svn 4642 issue

[Ozkan Sezer]

On Wed, Nov 30, 2011 at 12:20 PM, Ruben Van Boxem
 wrote:
> 2011/11/29 Ozkan Sezer 
>>
>> On Tue, Nov 29, 2011 at 6:41 PM, Ruben Van Boxem
>>  wrote:
>> > 2011/11/29 xunxun 
>> >>
>> >> winpthreads svn 4642 add a header file called pthread_compat.h, but is
>> >> missing in makefile.in when installing.
>> >
>> >
>> > You are correct, I missed that.
>> >
>> > Could someone please commit below patch and regenerate autoshizzle files
>> > (I
>> > don't have autotools installed, nor am I on Linux)?
>> > Index: Makefile.in
>> > ===
>> > --- Makefile.in (revision 4641)
>> > +++ Makefile.in (working copy)
>> > @@ -274,7 +274,7 @@
>> >    src/barrier.c  src/cond.c  src/misc.c  src/mutex.c  src/rwlock.c
>> >  src/spinlock.c  src/thread.c  src/ref.c  src/sem.c  src/sched.c \
>> >    src/winpthread_internal.h  src/clock.c src/nanosleep.c src/version.rc
>> >
>> > -include_HEADERS = include/pthread.h include/sched.h include/semaphore.h
>> > include/pthread_unistd.h include/pthread_time.h
>> > +include_HEADERS = include/pthread.h include/sched.h include/semaphore.h
>> > include/pthread_unistd.h include/pthread_time.h include/pthread_compat.h
>> >  DISTCHECK_CONFIGURE_FLAGS = --host=$(host_triplet)
>> >  noinst_LTLIBRARIES = libdummy.la
>> >  libwinpthread_la_LIBADD = libdummy.la
>> >
>> > Thanks!
>> >
>> > Ruben
>>
>> While you are working on that, remember that you were going to
>> fix that new header for clashes?
>
>
> Yes, and here is the required changes. It still includes the makefile.in
> bit, which needs some autotools love, which my windows box is unable to
> give. I tested with 64-bit GCC and MSVC.
>
> If anyone with autotools present could please apply this patch, I and anyone
> trying to use SVN HEAD would be very grateful!
>
> Ruben

Applied your patch at rev. 4646.

Also applied a patch at rev. 4647 to fix pid_t for 32 bits _MSC_VER

--
O.S.

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public