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

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() == 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() == 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

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 BUTAS" 
> ...
> 主题：[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

[Burkhardt, Glenn B UTAS]

It's not clear to me from this explanation why this code should fail:

pthread_setschedparam(pthread_self(), SCHED_OTHER, );

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

> Re: [Mingw-w64-public] winpthreads, pthread_setschedparam, and detached 
> threads
> From: lh mouse<lh_mouse@12...> - 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" <Glenn.Burkhardt@...>
发送日期：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

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

[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 alexey.paw...@gmail.com написал(а):
 
 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
  
 https://github.com/msys2/mingw-w64/commit/249898d9ae310959116efa333e4e3e690cf97452
 Rewrite the mutex implementation for better performance - 
 https://github.com/msys2/mingw-w64/commit/1968e60cd5d59727bb325d5b69c8f0d7a2f1fe1b
  
 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 
 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 
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

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

[Mattias Engdegård]

19 jun 2015 kl. 23.12 skrev Alexandre Pereira Nunes alexandre.nu...@gmail.com:

 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

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 matti...@acm.org wrote:
 19 jun 2015 kl. 23.12 skrev Alexandre Pereira Nunes 
 alexandre.nu...@gmail.com:

 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 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 k...@gentoo.org
 To: mingw-w64-public@lists.sourceforge.net
 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 pthread.h
 #include stdio.h

 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 k...@gentoo.org
To: mingw-w64-public@lists.sourceforge.net
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 pthread.h
 #include stdio.h

 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

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

[Alexey Pavlov]

ping?

2013/12/8 Fanael Linithien fana...@gmail.com:
 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=111408631iu=/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=84349831iu=/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=84349831iu=/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=84349831iu=/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 son...@telefonica.net
To: mingw-w64-public@lists.sourceforge.net
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 jo...@users.sourceforge.net
 To: mingw-w64-public@lists.sourceforge.net
 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=84349351iu=/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=84349351iu=/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=111408631iu=/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 son...@telefonica.net написал(а):

 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 son...@telefonica.net
 To: mingw-w64-public@lists.sourceforge.net
 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 jo...@users.sourceforge.net
 To: mingw-w64-public@lists.sourceforge.net
 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=84349351iu=/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=84349351iu=/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=111408631iu=/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=111408631iu=/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=111408631iu=/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 fana...@gmail.com:
 runs BEFORE enter_global_cs

Er, before global_spin_ctor, of course.

2013/12/5 Kai Tietz ktiet...@googlemail.com:
 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 limegreenso...@yahoo.com:
 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=111408631iu=/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=111408631iu=/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 fana...@gmail.com:
 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=111408631iu=/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=111408631iu=/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=111408631iu=/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=84349351iu=/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 jo...@users.sourceforge.net
To: mingw-w64-public@lists.sourceforge.net
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=84349351iu=/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=84349351iu=/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=84349351iu=/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 jon.for...@gmail.com




 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=84349351iu=/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=84349351iu=/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 jon.for...@gmail.com
 



 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=84349351iu=/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

[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 lrn1...@gmail.com
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

[NightStrike]

On Sun, Apr 14, 2013 at 9:09 AM, LRN lrn1...@gmail.com 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

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

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

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

[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

[Kai Tietz]

2012/7/18 niXman i.nix...@gmail.com:
 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

[Ozkan Sezer]

On Wed, Jul 18, 2012 at 2:02 PM, niXman i.nix...@gmail.com 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/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 dir
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 

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 i.nix...@gmail.com 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

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 i.nix...@gmail.com

 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=353559view=findpostp=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

[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

[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-api and GetLastError/SetLastError

[Kai Tietz]

2012/5/5 Ozkan Sezer seze...@gmail.com:
 On 5/4/12, niXman i.nix...@gmail.com wrote:
 Hi,

 This simple code change the last error which sometimes is not allowed:
 #include pthread.h
 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

[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

[niXman]

2012/5/5 niXman i.nix...@gmail.com:
 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 windows.h

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

[Ozkan Sezer]

On 5/4/12, niXman i.nix...@gmail.com wrote:
 Hi,

 This simple code change the last error which sometimes is not allowed:
 #include pthread.h
 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

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

[niXman]

2012/1/18 Ozkan Sezer seze...@gmail.com:
 On Wed, Jan 18, 2012 at 9:14 AM, niXman i.nix...@gmail.com 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

[Kai Tietz]

2012/1/18 niXman i.nix...@gmail.com:
 2012/1/18 Ozkan Sezer seze...@gmail.com:
 On Wed, Jan 18, 2012 at 9:14 AM, niXman i.nix...@gmail.com 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 Kai Tietz ktiet...@googlemail.com:
 2012/1/18 niXman i.nix...@gmail.com:
 2012/1/18 Ozkan Sezer seze...@gmail.com:
 On Wed, Jan 18, 2012 at 9:14 AM, niXman i.nix...@gmail.com 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 i.nix...@gmail.com:
 2012/1/18 Kai Tietz ktiet...@googlemail.com:
 2012/1/18 niXman i.nix...@gmail.com:
 2012/1/18 Ozkan Sezer seze...@gmail.com:
 On Wed, Jan 18, 2012 at 9:14 AM, niXman i.nix...@gmail.com 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

[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

[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 seze...@gmail.com:
 On Wed, Jan 4, 2012 at 6:32 PM, niXman i.nix...@gmail.com 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 seze...@gmail.com:
 On Wed, Jan 4, 2012 at 4:58 PM, Ruben Van Boxem
 vanboxem.ru...@gmail.com wrote:
 2012/1/4 niXman i.nix...@gmail.com

 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 seze...@gmail.com:
  On Wed, Dec 28, 2011 at 1:02 PM, niXman i.nix...@gmail.com wrote:
  Patch is attached.
  May be useful.
 
  2011/12/28 niXman i.nix...@gmail.com:
  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 windows.h
 
   #include pthread.h
  +#include pthread_time.h
 
   #define POW10_7                 1000
   #define POW10_9                 10
 
 
 
 
 
  2011/12/28 JonY jo...@users.sourceforge.net:
  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

[Ozkan Sezer]

On Tue, Jan 17, 2012 at 12:49 PM, niXman i.nix...@gmail.com 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

[Ozkan Sezer]

On Tue, Jan 17, 2012 at 1:24 PM, niXman i.nix...@gmail.com wrote:
 2012/1/17 Ozkan Sezer seze...@gmail.com:
 On Tue, Jan 17, 2012 at 12:49 PM, niXman i.nix...@gmail.com 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 pthread_time.h
 #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 2:22 PM, Kai Tietz ktiet...@googlemail.com wrote:
 2012/1/17 Ozkan Sezer seze...@gmail.com:
 On Tue, Jan 17, 2012 at 1:24 PM, niXman i.nix...@gmail.com wrote:
 2012/1/17 Ozkan Sezer seze...@gmail.com:
 On Tue, Jan 17, 2012 at 12:49 PM, niXman i.nix...@gmail.com 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 pthread_time.h
  #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

[niXman]

2012/1/17 Ozkan Sezer seze...@gmail.com:
 On Tue, Jan 17, 2012 at 1:24 PM, niXman i.nix...@gmail.com wrote:
 2012/1/17 Ozkan Sezer seze...@gmail.com:
 On Tue, Jan 17, 2012 at 12:49 PM, niXman i.nix...@gmail.com 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 pthread_time.h
  #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 Wed, Jan 18, 2012 at 8:05 AM, niXman i.nix...@gmail.com wrote:
 2012/1/17 Ozkan Sezer seze...@gmail.com:
 On Tue, Jan 17, 2012 at 1:24 PM, niXman i.nix...@gmail.com wrote:
 2012/1/17 Ozkan Sezer seze...@gmail.com:
 On Tue, Jan 17, 2012 at 12:49 PM, niXman i.nix...@gmail.com 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 pthread_time.h
  #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]

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 seze...@gmail.com:
 On Wed, Jan 18, 2012 at 8:05 AM, niXman i.nix...@gmail.com wrote:
 2012/1/17 Ozkan Sezer seze...@gmail.com:
 On Tue, Jan 17, 2012 at 1:24 PM, niXman i.nix...@gmail.com wrote:
 2012/1/17 Ozkan Sezer seze...@gmail.com:
 On Tue, Jan 17, 2012 at 12:49 PM, niXman i.nix...@gmail.com 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 pthread_time.h
  #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 9:14 AM, niXman i.nix...@gmail.com 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]

Hi Ozkan.

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


2011/12/28 Ozkan Sezer seze...@gmail.com:
 On Wed, Dec 28, 2011 at 1:02 PM, niXman i.nix...@gmail.com wrote:
 Patch is attached.
 May be useful.

 2011/12/28 niXman i.nix...@gmail.com:
 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 windows.h

  #include pthread.h
 +#include pthread_time.h

  #define POW10_7                 1000
  #define POW10_9                 10





 2011/12/28 JonY jo...@users.sourceforge.net:
 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
 

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

[Ruben Van Boxem]

2012/1/4 niXman i.nix...@gmail.com

 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 seze...@gmail.com:
  On Wed, Dec 28, 2011 at 1:02 PM, niXman i.nix...@gmail.com wrote:
  Patch is attached.
  May be useful.
 
  2011/12/28 niXman i.nix...@gmail.com:
  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 windows.h
 
   #include pthread.h
  +#include pthread_time.h
 
   #define POW10_7 1000
   #define POW10_9 10
 
 
 
 
 
  2011/12/28 JonY jo...@users.sourceforge.net:
  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
  

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

[Ozkan Sezer]

On Wed, Jan 4, 2012 at 4:58 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 2012/1/4 niXman i.nix...@gmail.com

 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 seze...@gmail.com:
  On Wed, Dec 28, 2011 at 1:02 PM, niXman i.nix...@gmail.com wrote:
  Patch is attached.
  May be useful.
 
  2011/12/28 niXman i.nix...@gmail.com:
  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 windows.h
 
   #include pthread.h
  +#include pthread_time.h
 
   #define POW10_7                 1000
   #define POW10_9                 10
 
 
 
 
 
  2011/12/28 JonY jo...@users.sourceforge.net:
  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.
 
 
 



--
O.S.

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources 

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 seze...@gmail.com:
 On Wed, Jan 4, 2012 at 4:58 PM, Ruben Van Boxem
 vanboxem.ru...@gmail.com wrote:
 2012/1/4 niXman i.nix...@gmail.com

 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 seze...@gmail.com:
  On Wed, Dec 28, 2011 at 1:02 PM, niXman i.nix...@gmail.com wrote:
  Patch is attached.
  May be useful.
 
  2011/12/28 niXman i.nix...@gmail.com:
  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 windows.h
 
   #include pthread.h
  +#include pthread_time.h
 
   #define POW10_7                 1000
   #define POW10_9                 10
 
 
 
 
 
  2011/12/28 JonY jo...@users.sourceforge.net:
  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.
 
 
 



 --
 O.S.

 

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

[Ozkan Sezer]

On Wed, Jan 4, 2012 at 6:32 PM, niXman i.nix...@gmail.com 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 seze...@gmail.com:
 On Wed, Jan 4, 2012 at 4:58 PM, Ruben Van Boxem
 vanboxem.ru...@gmail.com wrote:
 2012/1/4 niXman i.nix...@gmail.com

 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 seze...@gmail.com:
  On Wed, Dec 28, 2011 at 1:02 PM, niXman i.nix...@gmail.com wrote:
  Patch is attached.
  May be useful.
 
  2011/12/28 niXman i.nix...@gmail.com:
  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 windows.h
 
   #include pthread.h
  +#include pthread_time.h
 
   #define POW10_7                 1000
   #define POW10_9                 10
 
 
 
 
 
  2011/12/28 JonY jo...@users.sourceforge.net:
  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
 

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

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 jo...@users.sourceforge.net:
 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

[niXman]

Patch is attached.
May be useful.

2011/12/28 niXman i.nix...@gmail.com:
 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 jo...@users.sourceforge.net:
 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

[Ozkan Sezer]

On Wed, Dec 28, 2011 at 1:02 PM, niXman i.nix...@gmail.com wrote:
 Patch is attached.
 May be useful.

 2011/12/28 niXman i.nix...@gmail.com:
 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 windows.h

 #include pthread.h
+#include pthread_time.h

 #define POW10_7 1000
 #define POW10_9 10





 2011/12/28 JonY jo...@users.sourceforge.net:
 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

[niXman]

yep :)

2011/12/28 Ozkan Sezer seze...@gmail.com:
 On Wed, Dec 28, 2011 at 1:02 PM, niXman i.nix...@gmail.com wrote:
 Patch is attached.
 May be useful.

 2011/12/28 niXman i.nix...@gmail.com:
 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 windows.h

  #include pthread.h
 +#include pthread_time.h

  #define POW10_7                 1000
  #define POW10_9                 10





 2011/12/28 JonY jo...@users.sourceforge.net:
 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

[Ozkan Sezer]

On Wed, Dec 28, 2011 at 2:46 PM, niXman i.nix...@gmail.com wrote:
 yep :)


Applied the change to svn at rev. 4706.

 2011/12/28 Ozkan Sezer seze...@gmail.com:
 On Wed, Dec 28, 2011 at 1:02 PM, niXman i.nix...@gmail.com wrote:
 Patch is attached.
 May be useful.

 2011/12/28 niXman i.nix...@gmail.com:
 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 windows.h

  #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 svn 4642 issue

[Ruben Van Boxem]

2011/11/29 Ozkan Sezer seze...@gmail.com

 On Tue, Nov 29, 2011 at 6:41 PM, Ruben Van Boxem
 vanboxem.ru...@gmail.com wrote:
  2011/11/29 xunxun xunxun1...@gmail.com
 
  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.inbit, 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


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

Index: Makefile.in
===
--- Makefile.in (revision 4645)
+++ 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
Index: include/pthread_compat.h
===
--- include/pthread_compat.h(revision 4645)
+++ include/pthread_compat.h(working copy)
@@ -60,16 +60,22 @@
 #ifndef WIN_PTHREADS_PTHREAD_COMPAT_H
 #define WIN_PTHREADS_PTHREAD_COMPAT_H
 
-#ifdef _MSC_VER
+#ifdef __GNUC__
 
+#define WINPTHREADS_INLINE inline
+#define WINPTHREADS_ATTRIBUTE(X) __attribute__(X)
+#define WINPTHREADS_SECTION(X) __section__(X)
+
+#elif _MSC_VER
+
 #include pthread_time.h
 
 typedef __int64 pid_t;
 typedef int clockid_t;
 
-#define inline __inline
-#define __attribute__(X) __declspec X
-#define __section__(X) allocate(X)
+#define WINPTHREADS_INLINE __inline
+#define WINPTHREADS_ATTRIBUTE(X) __declspec X
+#define WINPTHREADS_SECTION(X) allocate(X)
 
 #endif
 
Index: src/misc.h
===
--- src/misc.h  (revision 4645)
+++ src/misc.h  (working copy)
@@ -82,7 +82,7 @@
 #define VALID(x)if (!(p)) return EINVAL;
 
 /* ms can be 64 bit, solve wrap-around issues: */
-static inline unsigned long dwMilliSecs(unsigned long long ms)
+static WINPTHREADS_INLINE unsigned long dwMilliSecs(unsigned long long ms)
 {
   if (ms = 0xULL) return 0xul;
   return (unsigned long) ms;
Index: src/rwlock.c
===
--- src/rwlock.c(revision 4645)
+++ src/rwlock.c(working copy)
@@ -31,9 +31,9 @@
 
 static spin_t rwl_global = {0,LIFE_SPINLOCK,1};
 
-static __attribute__((noinline)) int rwlock_static_init(pthread_rwlock_t *rw);
+static WINPTHREADS_ATTRIBUTE((noinline)) int 
rwlock_static_init(pthread_rwlock_t *rw);
 
-static __attribute__ ((noinline)) int rwl_unref(volatile pthread_rwlock_t 
*rwl, int res)
+static WINPTHREADS_ATTRIBUTE((noinline)) int rwl_unref(volatile 
pthread_rwlock_t *rwl, int res)
 {
 _spin_lite_lock(rwl_global);
 #ifdef WINPTHREAD_DBG
@@ -44,7 

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

[Ozkan Sezer]

On Wed, Nov 30, 2011 at 12:20 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 2011/11/29 Ozkan Sezer seze...@gmail.com

 On Tue, Nov 29, 2011 at 6:41 PM, Ruben Van Boxem
 vanboxem.ru...@gmail.com wrote:
  2011/11/29 xunxun xunxun1...@gmail.com
 
  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

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

[Ruben Van Boxem]

2011/11/30 Ozkan Sezer seze...@gmail.com

 On Wed, Nov 30, 2011 at 12:20 PM, Ruben Van Boxem
 vanboxem.ru...@gmail.com wrote:
  2011/11/29 Ozkan Sezer seze...@gmail.com
 
  On Tue, Nov 29, 2011 at 6:41 PM, Ruben Van Boxem
  vanboxem.ru...@gmail.com wrote:
   2011/11/29 xunxun xunxun1...@gmail.com
  
   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

[Ruben Van Boxem]

2011/11/29 xunxun xunxun1...@gmail.com

 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




 --
 Best Regards,
 xunxun



 --
 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 Tue, Nov 29, 2011 at 6:41 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 2011/11/29 xunxun xunxun1...@gmail.com

 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?

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

Re: [Mingw-w64-public] winpthreads and shared std::thread Operation not permitted exception

[Ozkan Sezer]

On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 Hi,

 As promised, I am investigating the shared libstdc++ std::thread problem
 with winpthreads. Basically, a simple Hello from thread test program
 throws an Operation not permitted std::system_error exception, which is
 most likely a result from winpthreads setting errno to EPERM. Test program
 below:

 #include iostream
 #include thread

 using namespace std;

 void f()
 {
     cout  hello from thread!  endl;
 }

 int main()
 {
     thread t1(f);
     thread t2(f);

     t1.join();
     t2.join();
 }

 Using any of my std::thread toolchains (4.6.3, 4.6.2-stdthread or
 4.7.0-stdthread) you can easily see that when not compiling this with
 -static, the program throws abovementioned exception.

 I did some looking into the issue, and came up with the following:
 1. There are 16 occurrences of EPERM in winpthreads (although not all are
 return codes I think), in pthreads-win32, there are only 6 discernable
 usages. This might be due to less correctness in pthreads-win32, but the
 difference is at the very least noticeable.
 2. I recompiled winpthreads, disabling each EPERM usage on  per-file basis,
 messing up correct functionality, but hoping to disrupt some pthreads error
 to libstdc++ exception conversion, but nothing there had any effect.
 3. Due to number 2, I'm now assuming there's some bad code in libstdc++,
 resulting in always throwing an exception. Strange enough, Google popped up
 this reverse situation for GCC 4.6 and Debian/glibc:
 http://stackoverflow.com/questions/7090623/c0x-thread-static-linking-problem

 Could it be that in the libstdc++ dll, this function __ghtread_active_p() is
 inlined in the dll (so to speak) to always cause this exception being thrown
 due to some incompatibility with the assumed semantics of inline and dll's?

 I'd see if building a libstdc++ dll with debug info helps, but frankly, dll
 debug info has always been disappointing in comparison to Linux so debug
 info.

 Any thoughts on how to best proceed are much appreciated.

 Ruben

 PS: currently winpthreads is broken due to the recent pthread_time.h change:
 In file included from
 m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
 from m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
 m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:84:28:
 error: expected '=', ',', ';', 'asm' or '__attribute__' before 'nanosleep'
 m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:86:28:
 error: expected '=', ',', ';', 'asm' or '__attribute__' before
 'clock_nanosleep'
 In file included from
 m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
 from m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
 m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:87:28:
 error: expected '=', ',', ';', 'asm' or '__attribute__' before
 'clock_getres'
 m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:88:28:
 error: expected '=', ',', ';', 'asm' or '__attribute__' before
 'clock_gettime'
 m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:89:28:
 error: expected '=', ',', ';', 'asm' or '__attribute__' before
 'clock_settime'
 I reincluded pthread.h for the time being in that file, working around
 this error. I notified Kai of this on IRC, but he hasn't responded yet, so
 I'm repeating it here for the record.

Rev. 4589 should fix it.

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
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 shared std::thread Operation not permitted exception

[Ruben Van Boxem]

2011/11/6 Ruben Van Boxem vanboxem.ru...@gmail.com

 2011/11/6 Ozkan Sezer seze...@gmail.com

 On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
 vanboxem.ru...@gmail.com wrote:
  Hi,
 
  As promised, I am investigating the shared libstdc++ std::thread problem
  with winpthreads. Basically, a simple Hello from thread test program
  throws an Operation not permitted std::system_error exception, which
 is
  most likely a result from winpthreads setting errno to EPERM. Test
 program
  below:
 
  #include iostream
  #include thread
 
  using namespace std;
 
  void f()
  {
  cout  hello from thread!  endl;
  }
 
  int main()
  {
  thread t1(f);
  thread t2(f);
 
  t1.join();
  t2.join();
  }
 
  Using any of my std::thread toolchains (4.6.3, 4.6.2-stdthread or
  4.7.0-stdthread) you can easily see that when not compiling this with
  -static, the program throws abovementioned exception.
 
  I did some looking into the issue, and came up with the following:
  1. There are 16 occurrences of EPERM in winpthreads (although not all
 are
  return codes I think), in pthreads-win32, there are only 6 discernable
  usages. This might be due to less correctness in pthreads-win32, but the
  difference is at the very least noticeable.
  2. I recompiled winpthreads, disabling each EPERM usage on  per-file
 basis,
  messing up correct functionality, but hoping to disrupt some pthreads
 error
  to libstdc++ exception conversion, but nothing there had any effect.
  3. Due to number 2, I'm now assuming there's some bad code in libstdc++,
  resulting in always throwing an exception. Strange enough, Google
 popped up
  this reverse situation for GCC 4.6 and Debian/glibc:
 
 http://stackoverflow.com/questions/7090623/c0x-thread-static-linking-problem
 
  Could it be that in the libstdc++ dll, this function
 __ghtread_active_p() is
  inlined in the dll (so to speak) to always cause this exception being
 thrown
  due to some incompatibility with the assumed semantics of inline and
 dll's?
 
  I'd see if building a libstdc++ dll with debug info helps, but frankly,
 dll
  debug info has always been disappointing in comparison to Linux so debug
  info.
 
  Any thoughts on how to best proceed are much appreciated.
 
  Ruben
 
  PS: currently winpthreads is broken due to the recent pthread_time.h
 change:
  In file included from
 
 m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
  from
 m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
 
 m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:84:28:
  error: expected '=', ',', ';', 'asm' or '__attribute__' before
 'nanosleep'
 
 m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:86:28:
  error: expected '=', ',', ';', 'asm' or '__attribute__' before
  'clock_nanosleep'
  In file included from
 
 m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
  from
 m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
 
 m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:87:28:
  error: expected '=', ',', ';', 'asm' or '__attribute__' before
  'clock_getres'
 
 m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:88:28:
  error: expected '=', ',', ';', 'asm' or '__attribute__' before
  'clock_gettime'
 
 m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:89:28:
  error: expected '=', ',', ';', 'asm' or '__attribute__' before
  'clock_settime'
  I reincluded pthread.h for the time being in that file, working around
  this error. I notified Kai of this on IRC, but he hasn't responded yet,
 so
  I'm repeating it here for the record.

 Rev. 4589 should fix it.


 Wow, didn't notice the type :-/ Thanks!


Argh... pthread_internal.h needs the pthread_t type (and thus a pthread.h
include):
libtool: compile:  x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
-I/m/Development/Source/mingw-w64/experimental/winpthreads
-I/m/Development/Source/mingw-w64/experimental/winpthreads/include
-DIN_WINPTHREAD -Wall -g -O2 -MT src/libwinpthread_la-clock.lo -MD -MP -MF
src/.deps/libwinpthread_la-clock.Tpo -c
/m/Development/Source/mingw-w64/experimental/winpthreads/src/clock.c
-DDLL_EXPORT -DPIC -o src/.libs/libwinpthread_la-clock.o
In file included from
m:/Development/Source/mingw-w64/experimental/winpthreads/src/clock.c:10:0:
m:/Development/Source/mingw-w64/experimental/winpthreads/src/winpthread_internal.h:25:59:
error: unknown type name 'pthread_t'

Thanks,

Ruben



 --
 RSA(R) Conference 2012
 Save $700 by Nov 18
 Register now
 http://p.sf.net/sfu/rsa-sfdev2dev1
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 

Re: [Mingw-w64-public] winpthreads and shared std::thread Operation not permitted exception

[Ozkan Sezer]

On Sun, Nov 6, 2011 at 3:54 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 2011/11/6 Ruben Van Boxem vanboxem.ru...@gmail.com

 2011/11/6 Ozkan Sezer seze...@gmail.com

 On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
 vanboxem.ru...@gmail.com wrote:
  Hi,
 
  As promised, I am investigating the shared libstdc++ std::thread
  problem
  with winpthreads. Basically, a simple Hello from thread test program
  throws an Operation not permitted std::system_error exception, which
  is
  most likely a result from winpthreads setting errno to EPERM. Test
  program
  below:
 
  #include iostream
  #include thread
 
  using namespace std;
 
  void f()
  {
      cout  hello from thread!  endl;
  }
 
  int main()
  {
      thread t1(f);
      thread t2(f);
 
      t1.join();
      t2.join();
  }
 
  Using any of my std::thread toolchains (4.6.3, 4.6.2-stdthread or
  4.7.0-stdthread) you can easily see that when not compiling this with
  -static, the program throws abovementioned exception.
 
  I did some looking into the issue, and came up with the following:
  1. There are 16 occurrences of EPERM in winpthreads (although not all
  are
  return codes I think), in pthreads-win32, there are only 6 discernable
  usages. This might be due to less correctness in pthreads-win32, but
  the
  difference is at the very least noticeable.
  2. I recompiled winpthreads, disabling each EPERM usage on  per-file
  basis,
  messing up correct functionality, but hoping to disrupt some pthreads
  error
  to libstdc++ exception conversion, but nothing there had any effect.
  3. Due to number 2, I'm now assuming there's some bad code in
  libstdc++,
  resulting in always throwing an exception. Strange enough, Google
  popped up
  this reverse situation for GCC 4.6 and Debian/glibc:
 
  http://stackoverflow.com/questions/7090623/c0x-thread-static-linking-problem
 
  Could it be that in the libstdc++ dll, this function
  __ghtread_active_p() is
  inlined in the dll (so to speak) to always cause this exception being
  thrown
  due to some incompatibility with the assumed semantics of inline and
  dll's?
 
  I'd see if building a libstdc++ dll with debug info helps, but frankly,
  dll
  debug info has always been disappointing in comparison to Linux so
  debug
  info.
 
  Any thoughts on how to best proceed are much appreciated.
 
  Ruben
 
  PS: currently winpthreads is broken due to the recent pthread_time.h
  change:
  In file included from
 
  m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
  from
  m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
 
  m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:84:28:
  error: expected '=', ',', ';', 'asm' or '__attribute__' before
  'nanosleep'
 
  m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:86:28:
  error: expected '=', ',', ';', 'asm' or '__attribute__' before
  'clock_nanosleep'
  In file included from
 
  m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
  from
  m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
 
  m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:87:28:
  error: expected '=', ',', ';', 'asm' or '__attribute__' before
  'clock_getres'
 
  m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:88:28:
  error: expected '=', ',', ';', 'asm' or '__attribute__' before
  'clock_gettime'
 
  m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:89:28:
  error: expected '=', ',', ';', 'asm' or '__attribute__' before
  'clock_settime'
  I reincluded pthread.h for the time being in that file, working
  around
  this error. I notified Kai of this on IRC, but he hasn't responded yet,
  so
  I'm repeating it here for the record.

 Rev. 4589 should fix it.

 Wow, didn't notice the type :-/ Thanks!

 Argh... pthread_internal.h needs the pthread_t type (and thus a pthread.h
 include):
 libtool: compile:  x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
 -I/m/Development/Source/mingw-w64/experimental/winpthreads
 -I/m/Development/Source/mingw-w64/experimental/winpthreads/include
 -DIN_WINPTHREAD -Wall -g -O2 -MT src/libwinpthread_la-clock.lo -MD -MP -MF
 src/.deps/libwinpthread_la-clock.Tpo -c
 /m/Development/Source/mingw-w64/experimental/winpthreads/src/clock.c
 -DDLL_EXPORT -DPIC -o src/.libs/libwinpthread_la-clock.o
 In file included from
 m:/Development/Source/mingw-w64/experimental/winpthreads/src/clock.c:10:0:
 m:/Development/Source/mingw-w64/experimental/winpthreads/src/winpthread_internal.h:25:59:
 error: unknown type name 'pthread_t'

 Thanks,

 Ruben

If you remove the winpthread_internal.h include from clock.c and nanosleep.c
do they compile OK?  AFAICS, those two don't need winpthread_internal.h.

--
O.S.

Re: [Mingw-w64-public] winpthreads and shared std::thread Operation not permitted exception

[Ruben Van Boxem]

2011/11/6 Ozkan Sezer seze...@gmail.com

 On Sun, Nov 6, 2011 at 3:54 PM, Ruben Van Boxem
 vanboxem.ru...@gmail.com wrote:
  2011/11/6 Ruben Van Boxem vanboxem.ru...@gmail.com
 
  2011/11/6 Ozkan Sezer seze...@gmail.com
 
  On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
  vanboxem.ru...@gmail.com wrote:
   Hi,
  
   As promised, I am investigating the shared libstdc++ std::thread
   problem
   with winpthreads. Basically, a simple Hello from thread test
 program
   throws an Operation not permitted std::system_error exception,
 which
   is
   most likely a result from winpthreads setting errno to EPERM. Test
   program
   below:
  
   #include iostream
   #include thread
  
   using namespace std;
  
   void f()
   {
   cout  hello from thread!  endl;
   }
  
   int main()
   {
   thread t1(f);
   thread t2(f);
  
   t1.join();
   t2.join();
   }
  
   Using any of my std::thread toolchains (4.6.3, 4.6.2-stdthread or
   4.7.0-stdthread) you can easily see that when not compiling this with
   -static, the program throws abovementioned exception.
  
   I did some looking into the issue, and came up with the following:
   1. There are 16 occurrences of EPERM in winpthreads (although not all
   are
   return codes I think), in pthreads-win32, there are only 6
 discernable
   usages. This might be due to less correctness in pthreads-win32, but
   the
   difference is at the very least noticeable.
   2. I recompiled winpthreads, disabling each EPERM usage on  per-file
   basis,
   messing up correct functionality, but hoping to disrupt some pthreads
   error
   to libstdc++ exception conversion, but nothing there had any effect.
   3. Due to number 2, I'm now assuming there's some bad code in
   libstdc++,
   resulting in always throwing an exception. Strange enough, Google
   popped up
   this reverse situation for GCC 4.6 and Debian/glibc:
  
  
 http://stackoverflow.com/questions/7090623/c0x-thread-static-linking-problem
  
   Could it be that in the libstdc++ dll, this function
   __ghtread_active_p() is
   inlined in the dll (so to speak) to always cause this exception being
   thrown
   due to some incompatibility with the assumed semantics of inline and
   dll's?
  
   I'd see if building a libstdc++ dll with debug info helps, but
 frankly,
   dll
   debug info has always been disappointing in comparison to Linux so
   debug
   info.
  
   Any thoughts on how to best proceed are much appreciated.
  
   Ruben
  
   PS: currently winpthreads is broken due to the recent pthread_time.h
   change:
   In file included from
  
  
 m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
   from
  
 m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
  
  
 m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:84:28:
   error: expected '=', ',', ';', 'asm' or '__attribute__' before
   'nanosleep'
  
  
 m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:86:28:
   error: expected '=', ',', ';', 'asm' or '__attribute__' before
   'clock_nanosleep'
   In file included from
  
  
 m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
   from
  
 m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
  
  
 m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:87:28:
   error: expected '=', ',', ';', 'asm' or '__attribute__' before
   'clock_getres'
  
  
 m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:88:28:
   error: expected '=', ',', ';', 'asm' or '__attribute__' before
   'clock_gettime'
  
  
 m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:89:28:
   error: expected '=', ',', ';', 'asm' or '__attribute__' before
   'clock_settime'
   I reincluded pthread.h for the time being in that file, working
   around
   this error. I notified Kai of this on IRC, but he hasn't responded
 yet,
   so
   I'm repeating it here for the record.
 
  Rev. 4589 should fix it.
 
  Wow, didn't notice the type :-/ Thanks!
 
  Argh... pthread_internal.h needs the pthread_t type (and thus a pthread.h
  include):
  libtool: compile:  x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
  -I/m/Development/Source/mingw-w64/experimental/winpthreads
  -I/m/Development/Source/mingw-w64/experimental/winpthreads/include
  -DIN_WINPTHREAD -Wall -g -O2 -MT src/libwinpthread_la-clock.lo -MD -MP
 -MF
  src/.deps/libwinpthread_la-clock.Tpo -c
  /m/Development/Source/mingw-w64/experimental/winpthreads/src/clock.c
  -DDLL_EXPORT -DPIC -o src/.libs/libwinpthread_la-clock.o
  In file included from
 
 m:/Development/Source/mingw-w64/experimental/winpthreads/src/clock.c:10:0:
 
 m:/Development/Source/mingw-w64/experimental/winpthreads/src/winpthread_internal.h:25:59:
  error: unknown type name 'pthread_t'
 
  Thanks,
 
  Ruben

 If you remove the 

Re: [Mingw-w64-public] winpthreads and shared std::thread Operation not permitted exception

[Ozkan Sezer]

On Sun, Nov 6, 2011 at 7:31 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 2011/11/6 Ozkan Sezer seze...@gmail.com

 On Sun, Nov 6, 2011 at 3:54 PM, Ruben Van Boxem
 vanboxem.ru...@gmail.com wrote:
  2011/11/6 Ruben Van Boxem vanboxem.ru...@gmail.com
 
  2011/11/6 Ozkan Sezer seze...@gmail.com
 
  On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
  vanboxem.ru...@gmail.com wrote:
   Hi,
  
   As promised, I am investigating the shared libstdc++ std::thread
   problem
   with winpthreads. Basically, a simple Hello from thread test
   program
   throws an Operation not permitted std::system_error exception,
   which
   is
   most likely a result from winpthreads setting errno to EPERM. Test
   program
   below:
  
   #include iostream
   #include thread
  
   using namespace std;
  
   void f()
   {
       cout  hello from thread!  endl;
   }
  
   int main()
   {
       thread t1(f);
       thread t2(f);
  
       t1.join();
       t2.join();
   }
  
   Using any of my std::thread toolchains (4.6.3, 4.6.2-stdthread or
   4.7.0-stdthread) you can easily see that when not compiling this
   with
   -static, the program throws abovementioned exception.
  
   I did some looking into the issue, and came up with the following:
   1. There are 16 occurrences of EPERM in winpthreads (although not
   all
   are
   return codes I think), in pthreads-win32, there are only 6
   discernable
   usages. This might be due to less correctness in pthreads-win32, but
   the
   difference is at the very least noticeable.
   2. I recompiled winpthreads, disabling each EPERM usage on  per-file
   basis,
   messing up correct functionality, but hoping to disrupt some
   pthreads
   error
   to libstdc++ exception conversion, but nothing there had any effect.
   3. Due to number 2, I'm now assuming there's some bad code in
   libstdc++,
   resulting in always throwing an exception. Strange enough, Google
   popped up
   this reverse situation for GCC 4.6 and Debian/glibc:
  
  
   http://stackoverflow.com/questions/7090623/c0x-thread-static-linking-problem
  
   Could it be that in the libstdc++ dll, this function
   __ghtread_active_p() is
   inlined in the dll (so to speak) to always cause this exception
   being
   thrown
   due to some incompatibility with the assumed semantics of inline and
   dll's?
  
   I'd see if building a libstdc++ dll with debug info helps, but
   frankly,
   dll
   debug info has always been disappointing in comparison to Linux so
   debug
   info.
  
   Any thoughts on how to best proceed are much appreciated.
  
   Ruben
  
   PS: currently winpthreads is broken due to the recent pthread_time.h
   change:
   In file included from
  
  
   m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
   from
  
   m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
  
  
   m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:84:28:
   error: expected '=', ',', ';', 'asm' or '__attribute__' before
   'nanosleep'
  
  
   m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:86:28:
   error: expected '=', ',', ';', 'asm' or '__attribute__' before
   'clock_nanosleep'
   In file included from
  
  
   m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
   from
  
   m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
  
  
   m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:87:28:
   error: expected '=', ',', ';', 'asm' or '__attribute__' before
   'clock_getres'
  
  
   m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:88:28:
   error: expected '=', ',', ';', 'asm' or '__attribute__' before
   'clock_gettime'
  
  
   m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:89:28:
   error: expected '=', ',', ';', 'asm' or '__attribute__' before
   'clock_settime'
   I reincluded pthread.h for the time being in that file, working
   around
   this error. I notified Kai of this on IRC, but he hasn't responded
   yet,
   so
   I'm repeating it here for the record.
 
  Rev. 4589 should fix it.
 
  Wow, didn't notice the type :-/ Thanks!
 
  Argh... pthread_internal.h needs the pthread_t type (and thus a
  pthread.h
  include):
  libtool: compile:  x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
  -I/m/Development/Source/mingw-w64/experimental/winpthreads
  -I/m/Development/Source/mingw-w64/experimental/winpthreads/include
  -DIN_WINPTHREAD -Wall -g -O2 -MT src/libwinpthread_la-clock.lo -MD -MP
  -MF
  src/.deps/libwinpthread_la-clock.Tpo -c
  /m/Development/Source/mingw-w64/experimental/winpthreads/src/clock.c
  -DDLL_EXPORT -DPIC -o src/.libs/libwinpthread_la-clock.o
  In file included from
 
  m:/Development/Source/mingw-w64/experimental/winpthreads/src/clock.c:10:0:
 
  

Re: [Mingw-w64-public] winpthreads issue

[Kai Tietz]

So, after long debugging and testing I finally found the cause.  Well,
I cleaned up winpthread-code a bit while debugging for it, and finally
found that the underlying issue was to be found in pthread.h and the
constant definition of PTHREAD_PROCESS_PRIVATE and
PTHREAD_PROCESS_SHARED.  Actual the values for those constants were
toggled.  By fixing this, libgomp seems to work as expected.

Regards,
Kai

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
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 issue

[Ruben Van Boxem]

2011/8/11 Kai Tietz ktiet...@googlemail.com:
 Hi Ruben,

 2011/8/11 Ruben Van Boxem vanboxem.ru...@gmail.com:
 Hi,

 In an effort to solve the issue(s) with winpthreads, I did the following:

 Using this source:
 #include omp.h
 #include stdio.h
 #include stdlib.h

 int main (int argc, char *argv[])
 {
 int nthreads, tid;
 /* Fork a team of threads giving them their own copies of variables */
 #pragma omp parallel private(nthreads, tid)
  {
  /* Obtain thread number */
  tid = omp_get_thread_num();
  printf(Hello World from thread = %d\n, tid);
  /* Only master thread does this */
  if (tid == 0)
    {
    nthreads = omp_get_num_threads();
    printf(Number of threads = %d\n, nthreads);
    }
  }  /* All threads join master thread and disband */
 }

 I tested execution after simple compilation:
 gcc -fopenmp omp_hello.c -o test.exe
 test.exe

 With sezero's 4.5 build
 (http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/sezero_4.5_20101002/)
 and my latest Personal Build
 (http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/4.6.2-1/)
 The difference between the two being pthreads-win32 vs winpthreads.
 The executable produced with pthreads-win32 (sezero) works and outputs
 what's expected. The winpthreads version hangs at 100% CPU (two cores
 full load) for more than 5 minutes and no output.

 To make sure it's not my personal build's problem, I checked against
 my 4.6.1-2 release, the latest with pthreads-win32. This works as
 sezero's build, and outputs immediately. It is not a GCC 4.6 issue, it
 is a winpthreads vs pthreads-win32 issue.

 Well, question here is where it actual stucks.  This notice is nice to
 know, but without more food why and where, I can't do pretty much
 here.  I assume it could be related to TLS stuff, but just by your
 description of it, I can't make much out of it.
 So I will come to build toolchain with libwinpthread in a couple of
 days and see if I can figure out why.

Thanks. Without a crash, it's hard to provide any more details. I'm
sure you're in a much better position to find what's going on. I just
tried to reduce to a testcase so to speak.

Note there is NO --enable-threads=posix involved. This is plain GCC
with --enable-threads=win32, and I just replaced the pthreads-win32
library with winpthreads.


 I also ran the pthreads-win32 testsuite, and it shows errors when ran
 against the winpthreads library.

 This won't work and this is no bug.  Testsuite from pthread-w32
 doesn't work 1:1 with winpthread.  There are some design-changes and
 implemenation details, which aren't compatible (by intention).  So you
 can spare in future this test as it has no conclusion.

Ok, I figured as much.

Thanksè


 Ruben

 Regards,
 Kai


--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. 
http://p.sf.net/sfu/wandisco-dev2dev
___
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 issue

[Kai Tietz]

Hi Ruben,

2011/8/11 Ruben Van Boxem vanboxem.ru...@gmail.com:
 Hi,

 In an effort to solve the issue(s) with winpthreads, I did the following:

 Using this source:
 #include omp.h
 #include stdio.h
 #include stdlib.h

 int main (int argc, char *argv[])
 {
 int nthreads, tid;
 /* Fork a team of threads giving them their own copies of variables */
 #pragma omp parallel private(nthreads, tid)
  {
  /* Obtain thread number */
  tid = omp_get_thread_num();
  printf(Hello World from thread = %d\n, tid);
  /* Only master thread does this */
  if (tid == 0)
    {
    nthreads = omp_get_num_threads();
    printf(Number of threads = %d\n, nthreads);
    }
  }  /* All threads join master thread and disband */
 }

 I tested execution after simple compilation:
 gcc -fopenmp omp_hello.c -o test.exe
 test.exe

 With sezero's 4.5 build
 (http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/sezero_4.5_20101002/)
 and my latest Personal Build
 (http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/4.6.2-1/)
 The difference between the two being pthreads-win32 vs winpthreads.
 The executable produced with pthreads-win32 (sezero) works and outputs
 what's expected. The winpthreads version hangs at 100% CPU (two cores
 full load) for more than 5 minutes and no output.

 To make sure it's not my personal build's problem, I checked against
 my 4.6.1-2 release, the latest with pthreads-win32. This works as
 sezero's build, and outputs immediately. It is not a GCC 4.6 issue, it
 is a winpthreads vs pthreads-win32 issue.

Well, question here is where it actual stucks.  This notice is nice to
know, but without more food why and where, I can't do pretty much
here.  I assume it could be related to TLS stuff, but just by your
description of it, I can't make much out of it.
So I will come to build toolchain with libwinpthread in a couple of
days and see if I can figure out why.

 I also ran the pthreads-win32 testsuite, and it shows errors when ran
 against the winpthreads library.

This won't work and this is no bug.  Testsuite from pthread-w32
doesn't work 1:1 with winpthread.  There are some design-changes and
implemenation details, which aren't compatible (by intention).  So you
can spare in future this test as it has no conclusion.

 Ruben

Regards,
Kai

--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. 
http://p.sf.net/sfu/wandisco-dev2dev
___
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 issue

[Kai Tietz]

2011/8/11 Kai Tietz ktiet...@googlemail.com:
 Hi Ruben,

 2011/8/11 Ruben Van Boxem vanboxem.ru...@gmail.com:
 Hi,

 In an effort to solve the issue(s) with winpthreads, I did the following:

 Using this source:
 #include omp.h
 #include stdio.h
 #include stdlib.h

 int main (int argc, char *argv[])
 {
 int nthreads, tid;
 /* Fork a team of threads giving them their own copies of variables */
 #pragma omp parallel private(nthreads, tid)
  {
  /* Obtain thread number */
  tid = omp_get_thread_num();
  printf(Hello World from thread = %d\n, tid);
  /* Only master thread does this */
  if (tid == 0)
    {
    nthreads = omp_get_num_threads();
    printf(Number of threads = %d\n, nthreads);
    }
  }  /* All threads join master thread and disband */
 }

 I tested execution after simple compilation:
 gcc -fopenmp omp_hello.c -o test.exe
 test.exe

 With sezero's 4.5 build
 (http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/sezero_4.5_20101002/)
 and my latest Personal Build
 (http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/4.6.2-1/)
 The difference between the two being pthreads-win32 vs winpthreads.
 The executable produced with pthreads-win32 (sezero) works and outputs
 what's expected. The winpthreads version hangs at 100% CPU (two cores
 full load) for more than 5 minutes and no output.

 To make sure it's not my personal build's problem, I checked against
 my 4.6.1-2 release, the latest with pthreads-win32. This works as
 sezero's build, and outputs immediately. It is not a GCC 4.6 issue, it
 is a winpthreads vs pthreads-win32 issue.

 Well, question here is where it actual stucks.  This notice is nice to
 know, but without more food why and where, I can't do pretty much
 here.  I assume it could be related to TLS stuff, but just by your
 description of it, I can't make much out of it.
 So I will come to build toolchain with libwinpthread in a couple of
 days and see if I can figure out why.

 I also ran the pthreads-win32 testsuite, and it shows errors when ran
 against the winpthreads library.

 This won't work and this is no bug.  Testsuite from pthread-w32
 doesn't work 1:1 with winpthread.  There are some design-changes and
 implemenation details, which aren't compatible (by intention).  So you
 can spare in future this test as it has no conclusion.

 Ruben

 Regards,
 Kai

Another important question here.  Do you use static or DLL version of
winpthread?

Regards,
Kai

--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. 
http://p.sf.net/sfu/wandisco-dev2dev
___
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's posix-threads only features (eg C++0x std::thread)

[Ruben Van Boxem]

Ok, I ran into some problems with --enable-threads=posix...

There are undefined references to

pthread_mutex_lock
pthread_mutex_unlock

and pretty much every other pthread function. I fear gcc isn't linking
to libpthread.a. This seems like a bug in the build system. I'll add
-lpthread to the LDFLAGS and see where that gets me. But doesn't gcc
link to libpthread on linux? Or are the pthread functions part of
glibc (and don't need explicit linking)?

Thanks,

Ruben

2011/6/12 K. Frank kfrank2...@gmail.com:
 Hello Ruben!

 On Sun, Jun 12, 2011 at 3:32 PM, Ruben Van Boxem
 vanboxem.ru...@gmail.com wrote:
 Hi,

 I'm upgrading my personal build to include Kai's winpthreads instead
 of the ancient pthreads-win32. Now, Kai already said on IRC that this
 would allow me to build all of GCC with posix threading, and I thought
 that maybe this would enable me to enable cool features available on
 Linux (like C++0x std::threads).

 That would be wonderful!  I would be especially eager to see a g++ 4.6
 version that had Kai's new winpthreads and std::thread support built in.

 My question is a simple one (eurhm, two): would passing
 --enable-threads=posix automagically enable the features missing with
 win32 threads? Are there any other GCC/runtime features hidden behind
 the posix threading model?

 I don't know the details of what --enable-threads=posix does.  As far
 as getting std::thread to work with pthreads on windows, I believe that
 there are some very minor changes you would need to make.  (I think
 that g++'s std::thread works out of the box using pthreads on linux.)

 I posted some notes to this list detailing the tweaks I needed to make
 to get std::thread working with pthreads:

   Pthreads-recipe for using std::thread with mingw (mingw32 / mingw-w64)

   
 http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTikwrRkzOuUdKOO2ShYSG7zqt8qq3QmXPfZsYhGa%40mail.gmail.comforum_name=mingw-w64-public

 I would think that the std::thread / gthread side of the equation should
 be the same.  Kai's winpthreads could well be a little different than the
 pthreads-w64 that I used.  As I remember it, the gthread wrapper that
 std::thread uses to access pthreads had some modest dependencies
 on the pthreads implementation, so it's possible that gthread would
 need to be tweaked a bit to work with Kai's implementation.

 I think std::thread will probably not work automagically, but I do think
 that it should be very easy to get it working.

These are the steps you need to take if GCC is configured with win32
threads, I think. And exactly what I'm trying to avoid when I use
posix thread completely. If I think wrong, I'll need to try this, but
I don't like the aspect of messing with the code that much.


 I understand using this option will theoretically reduce performance
 in stuff like openmp and GCC's internal threading, but as both are
 pretty limited anyways, I don't really see this impacting real-world
 performance much. Also, this will provide a larger test bed for Kai's
 implementation.

 I think that shooting std::thread at winpthreads would be a good test
 of some of its functionality.  Also, if you know how to run the g++ test
 suites (I don't know how to run them automatically, but I did run one or
 two manually.), the g++ std::thread-related test suites would be a good
 test for winpthreads, as well.

 Thanks!

 Ruben

 On the contrary, thanks to you (and Kai)!


 Best.


 K. Frank

 --
 EditLive Enterprise is the world's most technically advanced content
 authoring tool. Experience the power of Track Changes, Inline Image
 Editing and ensure content is compliant with Accessibility Checking.
 http://p.sf.net/sfu/ephox-dev2dev
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
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's posix-threads only features (eg C++0x std::thread)

[Ruben Van Boxem]

2011/6/13 Ruben Van Boxem vanboxem.ru...@gmail.com:
 Ok, I ran into some problems with --enable-threads=posix...

 There are undefined references to

 pthread_mutex_lock
 pthread_mutex_unlock

 and pretty much every other pthread function. I fear gcc isn't linking
 to libpthread.a. This seems like a bug in the build system. I'll add
 -lpthread to the LDFLAGS and see where that gets me. But doesn't gcc
 link to libpthread on linux? Or are the pthread functions part of
 glibc (and don't need explicit linking)?

Thanks to Kai's help on IRC, I now have built a GCC with posix
threading model. Of course, jon_y helped a lot too with the build
steps, which are quite complicated (winpthreads depends on libgcc).
First observations:

1. Qt Creator (which was built with a normal mingw-w64 toolchain,
namely, my 4.6.1-1 release, took 30 seconds to start up, with 100%
dual core load. Not normal, and probably either related to me not
rebuilding Qt/Qt Creator or a bug in winpthreads.

2. C++0x std::thread is not automagically enabled. Specifically, I
needed to perform the following manual steps (taken from K. Frank's
howto here: 
http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTikwrRkzOuUdKOO2ShYSG7zqt8qq3QmXPfZsYhGa%40mail.gmail.comforum_name=mingw-w64-public):
 - Add -D_POSIX_TIMEOUTS -D_GLIBCXX__PTHREADS
-D_GLIBCXX_HAS_GTHREADS to the commandline, along with -std=c++0x
of course.
 - Uncomment the line in bits/error_constants.h (strange, Explorer
won't show this file, but grep found it anyways... it's not hidden
either)
 - And that ends up in an undefined reference to std::thread::join().

I must be doing something wrong then :(

The first two need fixing though, but the patch Kai put into trunk
works as far as building GCC goes. I'll recompile Qt and Qt Creator to
see if the 30 second full load thing is a matter of recompiling or a
nifty bug in winpthreads.

Ruben

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
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's posix-threads only features (eg C++0x std::thread)

[Ruben Van Boxem]

2011/6/13 Ruben Van Boxem vanboxem.ru...@gmail.com:
 2011/6/13 Ruben Van Boxem vanboxem.ru...@gmail.com:
 Ok, I ran into some problems with --enable-threads=posix...

 There are undefined references to

 pthread_mutex_lock
 pthread_mutex_unlock

 and pretty much every other pthread function. I fear gcc isn't linking
 to libpthread.a. This seems like a bug in the build system. I'll add
 -lpthread to the LDFLAGS and see where that gets me. But doesn't gcc
 link to libpthread on linux? Or are the pthread functions part of
 glibc (and don't need explicit linking)?

 Thanks to Kai's help on IRC, I now have built a GCC with posix
 threading model. Of course, jon_y helped a lot too with the build
 steps, which are quite complicated (winpthreads depends on libgcc).
 First observations:

 1. Qt Creator (which was built with a normal mingw-w64 toolchain,
 namely, my 4.6.1-1 release, took 30 seconds to start up, with 100%
 dual core load. Not normal, and probably either related to me not
 rebuilding Qt/Qt Creator or a bug in winpthreads.

 2. C++0x std::thread is not automagically enabled. Specifically, I
 needed to perform the following manual steps (taken from K. Frank's
 howto here: 
 http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTikwrRkzOuUdKOO2ShYSG7zqt8qq3QmXPfZsYhGa%40mail.gmail.comforum_name=mingw-w64-public):
  - Add -D_POSIX_TIMEOUTS -D_GLIBCXX__PTHREADS
 -D_GLIBCXX_HAS_GTHREADS to the commandline, along with -std=c++0x
 of course.
  - Uncomment the line in bits/error_constants.h (strange, Explorer
 won't show this file, but grep found it anyways... it's not hidden
 either)
  - And that ends up in an undefined reference to std::thread::join().

 I must be doing something wrong then :(

Like for example adding --disable-static to the GCC configure line.
This probably caused the linker error, although the libstdc++.dll.a
import library should've been used, no? Qmake also wouldn't build,
because libstdc++.a was missing, that's how I found out. Maybe the
std::thread things aren't properly exported from the shared libstdc++
build?

I'm rebuilding now to see where I can get.


 The first two need fixing though, but the patch Kai put into trunk
 works as far as building GCC goes. I'll recompile Qt and Qt Creator to
 see if the 30 second full load thing is a matter of recompiling or a
 nifty bug in winpthreads.

 Ruben


--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
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's posix-threads only features (eg C++0x std::thread)

[K. Frank]

Hi Ruben!

On Mon, Jun 13, 2011 at 2:54 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 2011/6/13 Ruben Van Boxem vanboxem.ru...@gmail.com:
 2011/6/13 Ruben Van Boxem vanboxem.ru...@gmail.com:
 Ok, I ran into some problems with --enable-threads=posix...
 ...
 2. C++0x std::thread is not automagically enabled. Specifically, I
 needed to perform the following manual steps (taken from K. Frank's
 howto here: 
 http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTikwrRkzOuUdKOO2ShYSG7zqt8qq3QmXPfZsYhGa%40mail.gmail.comforum_name=mingw-w64-public):
  - Add -D_POSIX_TIMEOUTS -D_GLIBCXX__PTHREADS
 -D_GLIBCXX_HAS_GTHREADS to the commandline, along with -std=c++0x
 of course.
  - Uncomment the line in bits/error_constants.h (strange, Explorer
 won't show this file, but grep found it anyways... it's not hidden
 either)
  - And that ends up in an undefined reference to std::thread::join().

 I must be doing something wrong then :(

I had the same problem (undefined reference to std::thread::join())
getting std::thread to work.  Of course, in my case, I wasn't building
g++ -- I was using a pre-built g++, and tweaking the environment to
get std::thread to work.  (That's a long way of saying that even though
Ruben and I see the same symptom, we may have different causes.)

Anyway, std::thread is not pure header, but has some (compiled)
implementation somewhere.  (I assume that it's in libstdc++, but
I never tried to verify that.)  The source code for the implementation
for std::thread, thread.cc (and other files), is basically entirely
protected by:

   #if defined(_GLIBCXX_HAS_GTHREADS)  defined(_GLIBCXX_USE_C99_STDINT_TR1)

In my case -- linking against a pre-built libstdc++ (or whatever
library has the std::thread implementation) -- I got the undefined
reference, presumably because when the implementation
library was built, _GLIBCXX_HAS_GTHREADS was not defined.

So in my case, I simply added the source file thread.cc (and
some others) to the compile line when I compiled my program
that used std::thread.  Because that compile command had
_GLIBCXX_HAS_GTHREADS explicitly defined, the content of
thread.cc got compiled (no longer #ifdef'ed out) and provided the
function std::thread::join() for my program at link time.

However, if you're building a new g++ from the ground up (including
the standard libraries), then I would think that having

   _GLIBCXX_HAS_GTHREADS

(and other required macros) defined at build time would cause the
implementation for std::thread::join() contained in thread.cc to
be compiled and linked into libstdc++ (or whatever the right library
is), and therefore std::thread::join() should be available when you
compile and link a test program using your newly built g++.

Anyway, this is just a suggestion -- maybe Ruben is seeing a
different problem that happens to have a similar symptom.


 Like for example adding --disable-static to the GCC configure line.
 This probably caused the linker error, although the libstdc++.dll.a
 import library should've been used, no? Qmake also wouldn't build,
 because libstdc++.a was missing, that's how I found out. Maybe the
 std::thread things aren't properly exported from the shared libstdc++
 build?

This suggestion -- that libstdc++ does contain std::thread::join(), but
that it is not being exported -- seems plausible.

My copy of thread.cc (where std::thread::join() is implemented) came,
I believe, from the non-mingw-ized gnu source.  In any event, it does not
have any of that dllexport / dllimport stuff that I've never truly understood
the need for, but that seems to be necessary in the windows world.

Let's say that you're compiling thread.cc with

   _GLIBCXX_HAS_GTHREADS

defined.  Then the std::thread::join() implementation should be in the
object file and presumably also the library.  But if the mingw-w64 source
has a bug in that std::thread::join() isn't getting exported, then you
would get your undefined reference.  And the bug would never be
noticed until someone tried to build the library with

   _GLIBCXX_HAS_GTHREADS

defined.


 I'm rebuilding now to see where I can get.
 ...
 Ruben

Thanks again for your effort and for making your builds available.

Please let me know if there is any more detail I can offer that
might be helpful.

Best.


K. Frank

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
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's posix-threads only features (eg C++0x std::thread)

[K. Frank]

Hello Ruben!

On Sun, Jun 12, 2011 at 3:32 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 Hi,

 I'm upgrading my personal build to include Kai's winpthreads instead
 of the ancient pthreads-win32. Now, Kai already said on IRC that this
 would allow me to build all of GCC with posix threading, and I thought
 that maybe this would enable me to enable cool features available on
 Linux (like C++0x std::threads).

That would be wonderful!  I would be especially eager to see a g++ 4.6
version that had Kai's new winpthreads and std::thread support built in.

 My question is a simple one (eurhm, two): would passing
 --enable-threads=posix automagically enable the features missing with
 win32 threads? Are there any other GCC/runtime features hidden behind
 the posix threading model?

I don't know the details of what --enable-threads=posix does.  As far
as getting std::thread to work with pthreads on windows, I believe that
there are some very minor changes you would need to make.  (I think
that g++'s std::thread works out of the box using pthreads on linux.)

I posted some notes to this list detailing the tweaks I needed to make
to get std::thread working with pthreads:

   Pthreads-recipe for using std::thread with mingw (mingw32 / mingw-w64)

   
http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTikwrRkzOuUdKOO2ShYSG7zqt8qq3QmXPfZsYhGa%40mail.gmail.comforum_name=mingw-w64-public

I would think that the std::thread / gthread side of the equation should
be the same.  Kai's winpthreads could well be a little different than the
pthreads-w64 that I used.  As I remember it, the gthread wrapper that
std::thread uses to access pthreads had some modest dependencies
on the pthreads implementation, so it's possible that gthread would
need to be tweaked a bit to work with Kai's implementation.

I think std::thread will probably not work automagically, but I do think
that it should be very easy to get it working.

 I understand using this option will theoretically reduce performance
 in stuff like openmp and GCC's internal threading, but as both are
 pretty limited anyways, I don't really see this impacting real-world
 performance much. Also, this will provide a larger test bed for Kai's
 implementation.

I think that shooting std::thread at winpthreads would be a good test
of some of its functionality.  Also, if you know how to run the g++ test
suites (I don't know how to run them automatically, but I did run one or
two manually.), the g++ std::thread-related test suites would be a good
test for winpthreads, as well.

 Thanks!

 Ruben

On the contrary, thanks to you (and Kai)!


Best.


K. Frank

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public