Re: [Mingw-w64-public] winpthreads

[Alexey Pavlov]

> 28 июля 2015 г., в 7:09, Alexey Pavlov  написал(а):
> 
> Hi, guys!
> 
> Our users (MSYS2) report lot of crashes in different applications. We found 
> that that crash are happen after upgrading winpthreads and caused one or both 
> of two commits:
> Rewrite the pthread spin lock implementation - 
> https://github.com/msys2/mingw-w64/commit/249898d9ae310959116efa333e4e3e690cf97452
>  
> 
> Rewrite the mutex implementation for better performance - 
> https://github.com/msys2/mingw-w64/commit/1968e60cd5d59727bb325d5b69c8f0d7a2f1fe1b
>  
> 
> 
> I have no yet good testcase. This is GDB backtrace from one of our users 
> https://gist.github.com/achadwick/01c6a1b519a36dcdbe0a 
> 
> 
> Regards,
> Alexey.
> 
> 

For debugging issue can be used OpmeMP test
https://github.com/niXman/mingw-builds/blob/master/tests/omp_test.c 


Build it with «gcc omp_test.c -fopenmp -o omp_test.exe» and run.

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

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

[Adrien Nader]

Hi,

Have the executables using the winpthread library been rebuilt?

-- 
Adrien Nader

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

Re: [Mingw-w64-public] winpthreads

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

[PcX]

于 2011/8/11 18:15, Ruben Van Boxem 写道:
> Hi,
>
> In an effort to solve the issue(s) with winpthreads, I did the following:
>
> Using this source:
> #include
> #include
> #include
>
> 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.
>
> I also ran the pthreads-win32 testsuite, and it shows errors when ran
> against the winpthreads library.
>
> Ruben
>
> --
> 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
Yea, I also think it's not gcc4.6 OpenMP problem.
When I use gcc4.6 with winpthreads, my issue is the same as you.

-- 
Best Regards,
PcX


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

[Ruben Van Boxem]

2011/8/11 Kai Tietz :
> Hi Ruben,
>
> 2011/8/11 Ruben Van Boxem :
>> Hi,
>>
>> In an effort to solve the issue(s) with winpthreads, I did the following:
>>
>> Using this source:
>> #include 
>> #include 
>> #include 
>>
>> 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 :
> Hi,
>
> In an effort to solve the issue(s) with winpthreads, I did the following:
>
> Using this source:
> #include 
> #include 
> #include 
>
> 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 :
> Hi Ruben,
>
> 2011/8/11 Ruben Van Boxem :
>> Hi,
>>
>> In an effort to solve the issue(s) with winpthreads, I did the following:
>>
>> Using this source:
>> #include 
>> #include 
>> #include 
>>
>> 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 issue

[NightStrike]

On Thu, Aug 11, 2011 at 6:33 AM, Ruben Van Boxem
 wrote:
> 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.

You can attach with the debugger and see where it's spinning.

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

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

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

[PcX]

于 2011/8/16 15:53, 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

Good job, Kai.
Thanks.

--
Best Regards,
PcX

 * 英 文 - 检测到
 * 英文
 * 中文（简体）

 * 英文
 * 中文（简体）


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

[LRN]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14.04.2013 10:54, LRN wrote:
> This patch should integrate the testsuite imported from pthreads
> with winpthreads. (includes re-generated configure and Makefile.in
> - it is very sad that those are tracked in SVN).
> 

OK, here is a better patch - split into parts, without generated
files. Say "think you" to git-svn and its wonderful awesomeness!

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

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

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

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

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

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 testsuite

[Jim Michaels]

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

hopefully it's killable or terminates itself.
if you have a complete binary package with all dlls and such I could test it on 
my box and let you know how it goes. I have a cpu monitor, and taskmgr.exe can 
you can add a column for numthreads per process.






>
> From: LRN 
>To: mingw-w64-public@lists.sourceforge.net 
>Sent: Sunday, April 14, 2013 9:48 AM
>Subject: Re: [Mingw-w64-public] winpthreads testsuite
> 
>
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>On 14.04.2013 20:25, K. Frank wrote:
>> Hi LRN!
>> 
>> On Sun, Apr 14, 2013 at 10:16 AM, LRN <> wrote:
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>> 
>>> On 14.04.2013 17:55, K. Frank wrote:
>>>> Hello LRN!
>>>> 
>>>> On Sun, Apr 14, 2013 at 2:54 AM, LRN <...> wrote:
>>>>> ... This patch should integrate the testsuite imported from 
>>>>> pthreads with winpthreads. ...
>>>> 
>>>> Did you ever learn more about  / sort out the create / join
>>>> race condition you reported earlier?
>>> No. Ktietz gave me a patch, but it didn't fix the bug.
>>> 
>>>> (Sorry to semi-hijack the current thread.)
>>> One of the reasons why i want testsuite is that create2, in 
>>> particular, fails due to the create/join race. So it's not that
>>> bad :) ...
>> 
>> How frequently does the race occur?
>> 
>> The reason I ask is that I've used a couple of mingw-w64 builds
>> where std::thread is implemented on top of winpthreads.  I didn't
>> try any raw winpthreads create / join tests, but I did do the
>> equivalent at the std::thread level, namely instantiate / join some
>> std::threads.  When I ran my elementary (and not particularly
>> high-stress) join tests I didn't see any problems.  (This was on a
>> two-core windows 7 machine.)
>> 
>> So I'm wondering if the bug you found is relatively rare, or
>> whether I would need to run a more sophisticated test to catch it.
>> (Or maybe whether the specific std::thread use case avoids it
>> somehow.)
>As i have said, new testsuite triggers that bug for me (create2 test).
>
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v1.4.11 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iQEcBAEBAgAGBQJRat32AAoJEOs4Jb6SI2CwDNgIAL5XZGDZbfbCffTRdxIA4LoT
>St+DavJxeZ6O7kX9MPG8h322q32oGMd73woBLCMpbIDRlGE+h4BkkiqHpjrSr53m
>+7NOa9NCbrI1LAYL0Frh4i8sa11fMeiVjSOreFclqUn5D82x45kBzdwToQDE5u1o
>T/P4ctGMA+i+1q9r4U0PhAqzKNkHQK+aw4wKxmeDhqJco3OQmg5nUc1vLEqAtaG3
>S3Uee1x3fL51YO05qBnUNWgjDWs0njSVW+zPOTJRJtVufXICdLGAFGBBxaJ54fJs
>QcIRPSqqA78DIhkPe5FPfP+9fravJ2KR0schFFAKQ7oh5VMawF4AA2dCp4L0R8Q=
>=+NeW
>-END PGP SIGNATURE-
>
>--
>Precog is a next-generation analytics platform capable of advanced
>analytics on semi-structured data. The platform includes APIs for building
>apps and a phenomenal toolset for data science. Developers can use
>our toolset for easy data analysis & visualization. Get a free account!
>http://www2.precog.com/precogplatform/slashdotnewsletter
>___
>Mingw-w64-public mailing list
>Mingw-w64-public@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
>--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads testsuite

[NightStrike]

On Sun, Apr 14, 2013 at 9:09 AM, LRN  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 14.04.2013 10:54, LRN wrote:
>> This patch should integrate the testsuite imported from pthreads
>> with winpthreads. (includes re-generated configure and Makefile.in
>> - it is very sad that those are tracked in SVN).
>>
>
> OK, here is a better patch - split into parts, without generated
> files. Say "think you" to git-svn and its wonderful awesomeness!

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

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

Re: [Mingw-w64-public] winpthreads kill

[Jon]

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

Re: [Mingw-w64-public] winpthreads kill

[Ruben Van Boxem]

2013/11/27 Jon 

>
>
>>
>> Also: Where should I get the sources for winpthreads?
>>
>>
>
> http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-libraries/winpthreads/
>

winpthreads had an official release with 3.0.0. No need for development
versions anymore.

Ruben


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

Re: [Mingw-w64-public] winpthreads kill

[JonY]

On 11/28/2013 04:33, Ruben Van Boxem wrote:
> 2013/11/27 Jon 
> 
>>
>>
>>>
>>> Also: Where should I get the sources for winpthreads?
>>>
>>>
>>
>> http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-libraries/winpthreads/
>>
> 
> winpthreads had an official release with 3.0.0. No need for development
> versions anymore.
> 

Trunk includes some updates, so please do try it.





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

Re: [Mingw-w64-public] winpthreads kill

[Victor Bombi]

I dont know how to build. I always use CMake to create makefiles without 
mysys.
Do I need mysys? where do I get configure?

- Original Message - 
From: "JonY" 
To: 
Sent: Wednesday, November 27, 2013 11:10 PM
Subject: Re: [Mingw-w64-public] winpthreads kill


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





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


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

Re: [Mingw-w64-public] winpthreads kill

[Victor Bombi]

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

victor

- Original Message - 
From: "Victor Bombi" 
To: 
Sent: Thursday, November 28, 2013 3:04 PM
Subject: Re: [Mingw-w64-public] winpthreads kill


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


--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads kill

[Alexpux]

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

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

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

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

Regards,
Alexey.
> 
> victor
> 
> - Original Message - 
> From: "Victor Bombi" 
> To: 
> Sent: Thursday, November 28, 2013 3:04 PM
> Subject: Re: [Mingw-w64-public] winpthreads kill
> 
> 
>> I dont know how to build. I always use CMake to create makefiles without
>> mysys.
>> Do I need mysys? where do I get configure?
>> 
>> - Original Message - 
>> From: "JonY" 
>> To: 
>> Sent: Wednesday, November 27, 2013 11:10 PM
>> Subject: Re: [Mingw-w64-public] winpthreads kill
>> 
>> 
>>> --
>>> Rapidly troubleshoot problems before they affect your business. Most IT
>>> organizations don't have a clear picture of how application performance
>>> affects their revenue. With AppDynamics, you get 100% visibility into 
>>> your
>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>>> Pro!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>> 
>> 
>> 
>> 
>> 
>>> ___
>>> Mingw-w64-public mailing list
>>> Mingw-w64-public@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>> 
>> 
>> 
>> --
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics 
>> Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public 
> 
> 
> --
> Sponsored by Intel(R) XDK 
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Ruben Van Boxem]

2011/11/29 xunxun 

> winpthreads svn 4642 add a header file called pthread_compat.h, but is
> missing in makefile.in when installing.


You are correct, I missed that.

Could someone please commit below patch and regenerate autoshizzle files (I
don't have autotools installed, nor am I on Linux)?
Index: Makefile.in
===
--- Makefile.in (revision 4641)
+++ Makefile.in (working copy)
@@ -274,7 +274,7 @@
   src/barrier.c  src/cond.c  src/misc.c  src/mutex.c  src/rwlock.c
 src/spinlock.c  src/thread.c  src/ref.c  src/sem.c  src/sched.c \
   src/winpthread_internal.h  src/clock.c src/nanosleep.c src/version.rc

-include_HEADERS = include/pthread.h include/sched.h include/semaphore.h
include/pthread_unistd.h include/pthread_time.h
+include_HEADERS = include/pthread.h include/sched.h include/semaphore.h
include/pthread_unistd.h include/pthread_time.h include/pthread_compat.h
 DISTCHECK_CONFIGURE_FLAGS = --host=$(host_triplet)
 noinst_LTLIBRARIES = libdummy.la
 libwinpthread_la_LIBADD = libdummy.la

Thanks!

Ruben


>
>
> --
> 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
 wrote:
> 2011/11/29 xunxun 
>>
>> winpthreads svn 4642 add a header file called pthread_compat.h, but is
>> missing in makefile.in when installing.
>
>
> You are correct, I missed that.
>
> Could someone please commit below patch and regenerate autoshizzle files (I
> don't have autotools installed, nor am I on Linux)?
> Index: Makefile.in
> ===
> --- Makefile.in (revision 4641)
> +++ Makefile.in (working copy)
> @@ -274,7 +274,7 @@
>    src/barrier.c  src/cond.c  src/misc.c  src/mutex.c  src/rwlock.c
>  src/spinlock.c  src/thread.c  src/ref.c  src/sem.c  src/sched.c \
>    src/winpthread_internal.h  src/clock.c src/nanosleep.c src/version.rc
>
> -include_HEADERS = include/pthread.h include/sched.h include/semaphore.h
> include/pthread_unistd.h include/pthread_time.h
> +include_HEADERS = include/pthread.h include/sched.h include/semaphore.h
> include/pthread_unistd.h include/pthread_time.h include/pthread_compat.h
>  DISTCHECK_CONFIGURE_FLAGS = --host=$(host_triplet)
>  noinst_LTLIBRARIES = libdummy.la
>  libwinpthread_la_LIBADD = libdummy.la
>
> Thanks!
>
> Ruben

While you are working on that, remember that you were going to
fix that new header for clashes?

--
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/29 Ozkan Sezer 

> On Tue, Nov 29, 2011 at 6:41 PM, Ruben Van Boxem
>  wrote:
> > 2011/11/29 xunxun 
> >>
> >> winpthreads svn 4642 add a header file called pthread_compat.h, but is
> >> missing in makefile.in when installing.
> >
> >
> > You are correct, I missed that.
> >
> > Could someone please commit below patch and regenerate autoshizzle files
> (I
> > don't have autotools installed, nor am I on Linux)?
> > Index: Makefile.in
> > ===
> > --- Makefile.in (revision 4641)
> > +++ Makefile.in (working copy)
> > @@ -274,7 +274,7 @@
> >src/barrier.c  src/cond.c  src/misc.c  src/mutex.c  src/rwlock.c
> >  src/spinlock.c  src/thread.c  src/ref.c  src/sem.c  src/sched.c \
> >src/winpthread_internal.h  src/clock.c src/nanosleep.c src/version.rc
> >
> > -include_HEADERS = include/pthread.h include/sched.h include/semaphore.h
> > include/pthread_unistd.h include/pthread_time.h
> > +include_HEADERS = include/pthread.h include/sched.h include/semaphore.h
> > include/pthread_unistd.h include/pthread_time.h include/pthread_compat.h
> >  DISTCHECK_CONFIGURE_FLAGS = --host=$(host_triplet)
> >  noinst_LTLIBRARIES = libdummy.la
> >  libwinpthread_la_LIBADD = libdummy.la
> >
> > Thanks!
> >
> > Ruben
>
> While you are working on that, remember that you were going to
> fix that new header for clashes?
>

Yes, and here is the required changes. It still includes the
makefile.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);
 #ifd

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

[Ozkan Sezer]

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

Applied your patch at rev. 4646.

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

--
O.S.

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

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

[Ruben Van Boxem]

2011/11/30 Ozkan Sezer 

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

You're awesome as always, thanks!

Ruben


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

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

[Liu Hao]

On 2017/5/3 15:35, Christer Solskogen wrote:

I'm having a hard time (cross) compiling winpthreads (from 5.x branch)
with gcc 7.1.

Please try the attached patch.


--
Best regards,
LH_Mouse


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

[Ozkan Sezer]

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

Does the following one-liner fix it?

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

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

 #define POW10_7 1000
 #define POW10_9 10




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

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

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

 What am I doing wrongly?

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

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

[niXman]

yep :)

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

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



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

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

[Ozkan Sezer]

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

Applied the change to svn at rev. 4706.

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

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

--
O.S.

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

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

[niXman]

Hi Ozkan.

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


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

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



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

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

[Ruben Van Boxem]

2012/1/4 niXman 

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

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

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

Ruben


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

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

[Ozkan Sezer]

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

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

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

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

[niXman]

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

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

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

[Ozkan Sezer]

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

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

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

Do "test" this time, please.


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

 Hi Ozkan.

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


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

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

[niXman]

Hi Ozkan.

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

niXman.


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

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

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

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

 Ruben

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

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

[Ozkan Sezer]

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

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

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

--
O.S.

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

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

[Ozkan Sezer]

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

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

Does the attached patch help?

Kai, Jon:  OK to apply?

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

--
O.S.


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

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

[Kai Tietz]

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

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

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

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

Kai

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

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

[Ozkan Sezer]

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

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

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

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

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

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

> Kai
>

--
O.S.

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

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

[niXman]

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

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

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

niXman.


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

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

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

[Ozkan Sezer]

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

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

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

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

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

--
O.S.

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

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

[niXman]

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

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


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

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

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

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

[Ozkan Sezer]

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

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

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

--
O.S.

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

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

[niXman]

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


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

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

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

[Kai Tietz]

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

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

Regards,
Kai

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

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

[niXman]

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

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

niXman.


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

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

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

[Kai Tietz]

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

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

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

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

Kai

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

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

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

[Ozkan Sezer]

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

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

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


Kai?


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

--
O.S.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Kai Tietz]

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

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

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

Cheers,
Kai

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[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 :
> 2012/5/5 Kai Tietz:
>> Could somebody do tests if the LastError state can be really changed?
>
> About what tests there is a speech?

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

One more example:
#include 

struct C { ~C() {} };

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

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

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


-- 
Regards,
  niXman

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Mattias Engdegård]

19 jun 2015 kl. 23.12 skrev Alexandre Pereira Nunes :

> I came across this: https://sourceforge.net/p/mingw-w64/bugs/344/
> 
> Does anyone knows if that's still the case?

Yes. There is a patch, but it has not been cleared for release yet. It may take 
a few weeks more, given that people are on holiday. I shall try to accelerate 
the process.


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

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

[K. Frank]

Hi Mattias!

On Sat, Jun 20, 2015 at 4:32 AM, Mattias Engdegård  wrote:
> 19 jun 2015 kl. 23.12 skrev Alexandre Pereira Nunes 
> :
>
>> I came across this: https://sourceforge.net/p/mingw-w64/bugs/344/
>>
>> Does anyone knows if that's still the case?
>
> Yes. There is a patch, but it has not been cleared for release yet. It may 
> take a few weeks more, given that people are on holiday. I shall try to 
> accelerate the process.
> ...

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

Quoting from the bug report cited above:

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

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

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

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

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

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

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


Best.


K. Frank

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

Re: [Mingw-w64-public] winpthreads, 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, 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

[Burkhardt, Glenn B UTAS]

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

pthread_setschedparam(pthread_self(), SCHED_OTHER, ¶m);

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

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

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

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

--   
Best regards,
lh_mouse
2016-06-01

-
发件人："Burkhardt, Glenn BUTAS" 
发送日期：2016-05-31 23:11
收件人：mingw-w64-public@...
抄送：
主题：[Mingw-w64-public] winpthreads, pthread_setschedparam,
and detached threads

The way the winpthreads code is writing, the Windows handle for the thread is 
cleared when the thread is made detached.  That means that the 
pthread_setschedparam() call can't work.  So thread priorities for detached 
threads can only be set once, at thread creation, before the thread is 
detached, or as part of the pthread_create() call.

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




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

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

[lh mouse]

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

--   
Best regards,
lh_mouse
2016-06-01

-
发件人："Burkhardt, Glenn BUTAS" 
发送日期：2016-06-01 21:25
收件人：mingw-w64-public@lists.sourceforge.net
抄送：
主题：Re: [Mingw-w64-public] winpthreads, pthread_setschedparam,
 and detached threads

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

pthread_setschedparam(pthread_self(), SCHED_OTHER, ¶m);

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

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

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

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

--   
Best regards,
lh_mouse
2016-06-01

-
发件人："Burkhardt, Glenn BUTAS" 
发送日期：2016-05-31 23:11
收件人：mingw-w64-public@...
抄送：
主题：[Mingw-w64-public] winpthreads, pthread_setschedparam,
and detached threads

The way the winpthreads code is writing, the Windows handle for the thread is 
cleared when the thread is made detached.  That means that the 
pthread_setschedparam() call can't work.  So thread priorities for detached 
threads can only be set once, at thread creation, before the thread is 
detached, or as part of the pthread_create() call.

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




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

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

[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 library issue with dwarf toolchain

[niXman]

Alexey Pavlov 2013-11-28 11:35:
> Hi, all!
> 
> I'm have issue with winpthreads from trunk rev.6367 and later. It
> break for me dwarf toolchains with threads=posix. Most generated
> binaries with this toolchain crash on startup.
> For example, I build sqlite3 and winpthreads rev.6367 with debuginfo
> and has next GDB backtrace http://pastebin.com/8pdYsY3f.
> 
> If anyone has ability to resolve it I upload archive with breaked
> winpthreads+sqlite:
> https://www.dropbox.com/s/1wgqzvbcy0230h3/debug.tar.bz2

ping?


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

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

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

[Fanael Linithien]

I came up with a patch that fixes the issue for me.

The patch replaces the global critical section with a spinlock.
Critical sections require explicit initialization before use, which in
this case is not possible: register_frame_ctor (from libgcc), which
runs BEFORE enter_global_cs, tries to lock a mutex, which requires a
spinlock, which needs to be initialized in static_spin_init, which
tries to enter the global critical section, which is not initialized.
The result is a segfault somewhere in ntdll.

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


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


spinlock-remove-ctor.patch
Description: Binary data
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Kai Tietz]

2013/12/5 Fanael Linithien :
> I came up with a patch that fixes the issue for me.
>
> The patch replaces the global critical section with a spinlock.
> Critical sections require explicit initialization before use, which in
> this case is not possible: register_frame_ctor (from libgcc), which
> runs BEFORE enter_global_cs, tries to lock a mutex, which requires a
> spinlock, which needs to be initialized in static_spin_init, which
> tries to enter the global critical section, which is not initialized.
> The result is a segfault somewhere in ntdll.
>
> register_frame_ctor has constructor priority of 0, so setting the
> priority of global_spin_ctor wouldn't cut it.
>
>
> I'm not sure what is the official way to send patches, so I'm posting it here.

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

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

Kai

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[dw]

A few thoughts:

1) Shouldn't global_lock be __LONG32?
2) Would it make sense for the exchange on global_lock to be done as a 
single operation (ie InterlockedCompareExchange)?


dw

On 12/5/2013 10:45 AM, Fanael Linithien wrote:

I came up with a patch that fixes the issue for me.

The patch replaces the global critical section with a spinlock.
Critical sections require explicit initialization before use, which in
this case is not possible: register_frame_ctor (from libgcc), which
runs BEFORE enter_global_cs, tries to lock a mutex, which requires a
spinlock, which needs to be initialized in static_spin_init, which
tries to enter the global critical section, which is not initialized.
The result is a segfault somewhere in ntdll.

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


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


--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk


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


--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Fanael Linithien]

2013/12/5 Fanael Linithien :
> runs BEFORE enter_global_cs

Er, before global_spin_ctor, of course.

2013/12/5 Kai Tietz :
> Nice catch.  This describes at least the runtime-failure we got reported.
> Did you tested regressions for this patch?

I have. All tests from tests_pthread pass.


2013/12/5 dw :
> 1) Shouldn't global_lock be __LONG32?

Probably not. InterlockedExchange takes volatile LONG*.

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

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

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Fanael Linithien]

Ping?

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Alexey Pavlov]

ping?

2013/12/8 Fanael Linithien :
> Ping?
>
> --
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

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

[Kai Tietz]

Sorry for the delay.  Patch is ok.  Does somebody would apply it to
trunk (and if JonY doesn't object also to v3-branch)?

Thanks,
Kai

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

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

[JonY]

On 12/12/2013 02:32, Kai Tietz wrote:
> Sorry for the delay.  Patch is ok.  Does somebody would apply it to
> trunk (and if JonY doesn't object also to v3-branch)?
> 
> Thanks,
> Kai
> 

Done, trunk r6411 and stable/v3.x r6412.





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

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

[Victor Bombi]

May be it has some relation with?

http://sourceforge.net/p/mingw-w64/mailman/message/31749147/

- Original Message - 
From: "Keri Harris" 
To: 
Sent: Thursday, March 19, 2015 3:27 PM
Subject: [Mingw-w64-public] winpthreads cleanup handlers not called 
afterpthread_exit()


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


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

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

[Keri Harris]

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

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

Looking at the definition for pthread_cleanup_push() in 
winpthreads/include/pthread.h, it looks like the cleanup stack is only 
accessible via a local variable, and no mechanism exists to call these 
handlers unless pthread_cleanup_pop() is explicitly called. 
pthreads-win32 uses __try/__finally (for SEH) or 
pthread_setspecific()/pthread_getspecific() (for C cleanup) to ensure 
they're always called.


> - Original Message -
> From: "Keri Harris" 
> To: 
> Sent: Thursday, March 19, 2015 3:27 PM
> Subject: [Mingw-w64-public] winpthreads cleanup handlers not called
> afterpthread_exit()
>
>
>> I've noticed some unexpected behaviour with winpthreads which I believe
>> is a bug. Thread-cancellation cleanup handlers are not called when a
>> thread terminates due to a call to pthread_exit(). This is unexpected;
>> the pthread_cleanup_push(), pthread_cleanup_pop() specification [1]
>> mentions:
>>
>>  The cancellation cleanup handler shall be popped from the
>> cancellation cleanup stack
>>  and invoked with the argument arg when:
>>
>>  The thread exits (that is, calls pthread_exit()).
>>
>> An example program illustrating winpthreads failing to invoke cleanup
>> handlers follows:
>>
>>
>> #include 
>> #include 
>>
>> void* cleanup_func(void *arg)
>> {
>>  printf("cleanup_func()\n");
>> }
>>
>> void* func(void *arg)
>> {
>>  printf("func()\n");
>>  pthread_cleanup_push(cleanup_func, 0);
>>  pthread_exit(NULL);
>>  pthread_cleanup_pop(1);
>> }
>>
>> int main()
>> {
>>  pthread_t t;
>>  void *ret;
>>
>>  pthread_create(&t, NULL, func, (void*)NULL);
>>  pthread_join(t, &ret);
>>
>>  return 0;
>> }
>>
>>
>>
>> Thanks
>>
>> Keri
>>
>> [1]
>> http://pubs.opengroup.org/onlinepubs/95399/functions/pthread_cleanup_pop.html
>>
>>
>> --
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for
>> all
>> things parallel software development, from weekly thought leadership blogs
>> to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>


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

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

[Ozkan Sezer]

On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
 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 
> #include 
>
> 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  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 Ozkan Sezer 

> On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
>  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 
> > #include 
> >
> > 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  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!

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

> 2011/11/6 Ozkan Sezer 
>
>> On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
>>  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 
>> > #include 
>> >
>> > 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  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
>> Sav

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
 wrote:
> 2011/11/6 Ruben Van Boxem 
>>
>> 2011/11/6 Ozkan Sezer 
>>>
>>> On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
>>>  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 
>>> > #include 
>>> >
>>> > 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  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

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

[Ruben Van Boxem]

2011/11/6 Ozkan Sezer 

> On Sun, Nov 6, 2011 at 3:54 PM, Ruben Van Boxem
>  wrote:
> > 2011/11/6 Ruben Van Boxem 
> >>
> >> 2011/11/6 Ozkan Sezer 
> >>>
> >>> On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
> >>>  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 
> >>> > #include 
> >>> >
> >>> > 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  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

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
 wrote:
> 2011/11/6 Ozkan Sezer 
>>
>> On Sun, Nov 6, 2011 at 3:54 PM, Ruben Van Boxem
>>  wrote:
>> > 2011/11/6 Ruben Van Boxem 
>> >>
>> >> 2011/11/6 Ozkan Sezer 
>> >>>
>> >>> On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
>> >>>  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 
>> >>> > #include 
>> >>> >
>> >>> > 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  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.

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

[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 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
 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.com&forum_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

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 :
> Hello Ruben!
>
> On Sun, Jun 12, 2011 at 3:32 PM, Ruben Van Boxem
>  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.com&forum_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 :
> 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.com&forum_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 :
> 2011/6/13 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 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.com&forum_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
 wrote:
> 2011/6/13 Ruben Van Boxem :
>> 2011/6/13 Ruben Van Boxem :
>>> 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.com&forum_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)

[Ruben Van Boxem]

2011/6/13 K. Frank :
> Hi Ruben!
>
> On Mon, Jun 13, 2011 at 2:54 PM, Ruben Van Boxem
>  wrote:
>> 2011/6/13 Ruben Van Boxem :
>>> 2011/6/13 Ruben Van Boxem :
 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.com&forum_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.

No I think you're spot on. I'm sure Kai has some other patches in GCC
trunk that enable this (he assured he had the std::thread stuff
working). If he would be so kind as to provide a date/revision I'll
cherry-pick that change into my GCC 4.6 and see where that gets me.

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

I think I'm wrong here, the macro isn't defined (even in the final g++
I have I have to define it explicitely...). I'm sure these classes are
defined just like any other libstdc++ class or function. Anyway, I'm
using vanilla GCC, except for two patches that allowed me to use posix
threads by Kai from trunk.

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

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 5:00 PM, Ruben Van Boxem
 wrote:
> 2011/6/13 K. Frank :
>> Hi Ruben!
>> On Mon, Jun 13, 2011 at 2:54 PM, Ruben Van Boxem
>>  wrote:
> ...
 2. C++0x std::thread is not automagically enabled.
 ...
  - And that ends up in an undefined reference to "std::thread::join()".
 ...
>> 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)
>> ...
>> Anyway, this is just a suggestion -- maybe Ruben is seeing a
>> different problem that happens to have a similar symptom.
>
> No I think you're spot on. I'm sure Kai has some other patches in GCC
> trunk that enable this (he assured he had the std::thread stuff
> working). If he would be so kind as to provide a date/revision I'll
> cherry-pick that change into my GCC 4.6 and see where that gets me.
> ...
>>> 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.
>> ...
> I think I'm wrong here, the macro isn't defined (even in the final g++
> I have I have to define it explicitely...). I'm sure these classes are
> defined just like any other libstdc++ class or function. Anyway, I'm
> using vanilla GCC, except for two patches that allowed me to use posix
> threads by Kai from trunk.

Okay.  Assuming that you have the export stuff set up properly, I'm
guessing that you will want to define

   _POSIX_TIMEOUTS
   _GLIBCXX__PTHREADS   (note the double underscore, "__")
   _GLIBCXX_HAS_GTHREADS

when you build the library.

Note that _GLIBCXX_USE_C99_STDINT_TR1 should also be defined,
but I'm guessing that it gets defined automatically in the "standard"
configuration.

Now the above macros must get defined somehow when g++ is
built for linux.  How, I don't know.  It might be nice to figure out
the "official" way to activate these macros, but when I was poking
around, it was completely opaque to me, so just defining them by
hand might be the most practical way to go.

> ...
> Thanks for the continued assistance.

Not at all.  I'm eager to get a stable build with integrated std::thread.

Happy hacking!


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 patch for pthread_getspecific()/pthread_setspecific() function for restore WIN last error code

[Ozkan Sezer]

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

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

--
O.S.


winpthreads_lasterror.patch
Description: Binary data
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public