在 2022-05-02 20:25, Martin Storsjö 写道:
On Mon, 2 May 2022, LIU Hao wrote:
--
LGTM, thanks!
Thanks. Amended and pushed to master.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
___
Mingw-w64-public mailing l
在 2022-05-02 20:20, LIU Hao 写道:
+# if defined(WINPTHREADS_USE_DLLIMPORT)
+#define WINPTHREAD_API __declspec(dllimport) /* user wants explicit
`dllimport` */
# else
-#define WINPTHREAD_API __declspec(dllimport)
-# endif
+#define WINPTHREAD_API /* the default; auto imported in
On Mon, 2 May 2022, LIU Hao wrote:
--
LGTM, thanks!
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Best regards,
LIU Hao
From b3d95248f2f8bf2e5863671dbc00ff8dcf2b8aac Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Mon, 2 May 2022 19:53:55 +0800
Subject: [PATCH] winpthreads: Do not use `dllimport` when building 3rd-party
DLLs (V4)
Existent code that is linked against the winpthreads static
On 05/04/2017 01:13 AM, Liu Hao wrote:
> On 2017/5/4 13:54, Daniel Santos wrote:
>> I see one in libgcc, but I guess you would have to add that to your
>> link. I presume it's in the dynamic portion.
> As Kai said yesterday on IRC, in the case of cross compiling libpthread
> has to be available pr
On 2017/5/4 13:54, Daniel Santos wrote:
> I see one in libgcc, but I guess you would have to add that to your
> link. I presume it's in the dynamic portion.
As Kai said yesterday on IRC, in the case of cross compiling libpthread
has to be available prior to libgcc. That is the reason why we link
On 05/03/2017 10:17 AM, Liu Hao wrote:
> On 2017/5/3 18:56, Christer Solskogen wrote:
>> On 03.05.2017 10.23, Liu Hao wrote:
>>> On 2017/5/3 15:35, Christer Solskogen wrote:
I'm having a hard time (cross) compiling winpthreads (from 5.x branch)
with gcc 7.1.
>>> Please try the attached pa
On 2017/5/3 18:56, Christer Solskogen wrote:
> On 03.05.2017 10.23, Liu Hao wrote:
>> On 2017/5/3 15:35, Christer Solskogen wrote:
>>> I'm having a hard time (cross) compiling winpthreads (from 5.x branch)
>>> with gcc 7.1.
>> Please try the attached patch.
>>
>
> Works! Thanks! \o/
>
This is nothi
On 03.05.2017 10.23, Liu Hao wrote:
> On 2017/5/3 15:35, Christer Solskogen wrote:
>> I'm having a hard time (cross) compiling winpthreads (from 5.x branch)
>> with gcc 7.1.
> Please try the attached patch.
>
Works! Thanks! \o/
--
chs
--
On 2017/5/3 15:35, Christer Solskogen wrote:
I'm having a hard time (cross) compiling winpthreads (from 5.x branch)
with gcc 7.1.
Please try the attached patch.
--
Best regards,
LH_Mouse
From 4fa48b2af092a3b8615cef39b6e0036e20481c3f Mon Sep 17 00:00:00 2001
From: Liu Hao
Date: Wed, 3 May 20
I'm having a hard time (cross) compiling winpthreads (from 5.x branch)
with gcc 7.1.
make[2]: Entering directory
'/tmp/obj/_build/winpthreads.cross.i686-w64-mingw32'
/bin/bash ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -Wall
-DWIN32_LEAN_AND_MEAN -O2 -pipe -no-undefined -version-inf
g!
> 发件人："Burkhardt, Glenn B UTAS"
> ...
> 主题：[Mingw-w64-public] winpthreads, pthread_setschedparam,
> and detached threads
>
> The way the winpthreads code is writing, the Windows handle for the thread is
> cleared when the thread is made detached. T
enn BUTAS"
发送日期：2016-06-01 21:25
收件人：mingw-w64-public@lists.sourceforge.net
抄送：
主题：Re: [Mingw-w64-public] winpthreads, pthread_setschedparam,
and detached threads
It's not clear to me from this explanation why this code should fail:
pthread_setschedparam(pthread_self(),
It's not clear to me from this explanation why this code should fail:
pthread_setschedparam(pthread_self(), SCHED_OTHER, ¶m);
but in winpthreads, for a detached thread, it will.
> Re: [Mingw-w64-public] winpthreads, pthread_setschedparam, and detached
> threads
>
.
--
Best regards,
lh_mouse
2016-06-01
-
发件人："Burkhardt, Glenn BUTAS"
发送日期：2016-05-31 23:11
收件人：mingw-w64-public@lists.sourceforge.net
抄送：
主题：[Mingw-w64-public] winpthreads, pthread_set
Hi Glenn!
On Tue, May 31, 2016 at 11:11 AM, Burkhardt, Glenn BUTAS
wrote:
> The way the winpthreads code is writing, the Windows handle for the thread is
> cleared when the thread is made detached. That means that the
> pthread_setschedparam() call can't work. So thread priorities for
The way the winpthreads code is writing, the Windows handle for the thread is
cleared when the thread is made detached. That means that the
pthread_setschedparam() call can't work. So thread priorities for detached
threads can only be set once, at thread creation, before the thread is
detache
Hi,
Consider such code:
*
{
pthread_spinlock_t* lock_pointer;
pthread_spinlock_t lock_value;
lock_pointer = (pthread_spinlock_t*)calloc( 1,
sizeof(pthread_spinlock_t) );
pthread_spin_init( lock_pointer, 0 );
lock_value = *lock_pointer; /* == -1 */
free( lock_pointer );
**
Hi,
Have the executables using the winpthread library been rebuilt?
--
Adrien Nader
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.s
> For debugging issue can be used OpmeMP test
> https://github.com/niXman/mingw-builds/blob/master/tests/omp_test.c
>
> Build it with «gcc omp_test.c -fopenmp -o omp_test.exe» and run.
No crash when I run that code. Is this the same for everybody else?
Perhaps you could find a different test case
> 28 июля 2015 г., в 7:09, Alexey Pavlov написал(а):
>
> Hi, guys!
>
> Our users (MSYS2) report lot of crashes in different applications. We found
> that that crash are happen after upgrading winpthreads and caused one or both
> of two commits:
> Rewrite the pthread spin lock implementation -
Hi, guys!
Our users (MSYS2) report lot of crashes in different applications. We found
that that crash are happen after upgrading winpthreads and caused one or both
of two commits:
Rewrite the pthread spin lock implementation -
https://github.com/msys2/mingw-w64/commit/249898d9ae310959116efa333e
Hi Mattias!
On Sat, Jun 20, 2015 at 4:32 AM, Mattias Engdegård wrote:
> 19 jun 2015 kl. 23.12 skrev Alexandre Pereira Nunes
> :
>
>> I came across this: https://sourceforge.net/p/mingw-w64/bugs/344/
>>
>> Does anyone knows if that's still the case?
>
> Yes. There is a patch, but it has not been
19 jun 2015 kl. 23.12 skrev Alexandre Pereira Nunes :
> I came across this: https://sourceforge.net/p/mingw-w64/bugs/344/
>
> Does anyone knows if that's still the case?
Yes. There is a patch, but it has not been cleared for release yet. It may take
a few weeks more, given that people are on ho
I came across this: https://sourceforge.net/p/mingw-w64/bugs/344/
Does anyone knows if that's still the case?
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourcefo
ds-win32 uses __try/__finally (for SEH) or
pthread_setspecific()/pthread_getspecific() (for C cleanup) to ensure
they're always called.
> - Original Message -
> From: "Keri Harris"
> To:
> Sent: Thursday, March 19, 2015 3:27 PM
> Subject: [Mingw-w6
May be it has some relation with?
http://sourceforge.net/p/mingw-w64/mailman/message/31749147/
- Original Message -
From: "Keri Harris"
To:
Sent: Thursday, March 19, 2015 3:27 PM
Subject: [Mingw-w64-public] winpthreads cleanup handlers not called
afterpthread_exit()
>
I've noticed some unexpected behaviour with winpthreads which I believe
is a bug. Thread-cancellation cleanup handlers are not called when a
thread terminates due to a call to pthread_exit(). This is unexpected;
the pthread_cleanup_push(), pthread_cleanup_pop() specification [1]
mentions:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This was first observed in winpthreads from trunk r6478.
ktietz claimed to have found some problems with mutex destruction, and
committed r6481, then r6482.
After hours of running glimagesink and digging highly verbose log
output, i came to a conclusi
On 12/12/2013 02:32, Kai Tietz wrote:
> Sorry for the delay. Patch is ok. Does somebody would apply it to
> trunk (and if JonY doesn't object also to v3-branch)?
>
> Thanks,
> Kai
>
Done, trunk r6411 and stable/v3.x r6412.
signature.asc
Description: OpenPGP digital signature
-
Sorry for the delay. Patch is ok. Does somebody would apply it to
trunk (and if JonY doesn't object also to v3-branch)?
Thanks,
Kai
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizatio
ping?
2013/12/8 Fanael Linithien :
> Ping?
>
> --
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/cl
ictor Bombi"
> To:
> Sent: Thursday, November 28, 2013 3:04 PM
> Subject: Re: [Mingw-w64-public] winpthreads kill
>
>
>> I dont know how to build. I always use CMake to create makefiles without
>> mysys.
>> Do I need mysys? where do I get configure?
>&
"
To:
Sent: Thursday, November 28, 2013 3:04 PM
Subject: Re: [Mingw-w64-public] winpthreads kill
>I dont know how to build. I always use CMake to create makefiles without
> mysys.
> Do I need mysys? where do I get configure?
>
> - Original Message -
> From: &quo
Ping?
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
2013/12/5 Fanael Linithien :
> runs BEFORE enter_global_cs
Er, before global_spin_ctor, of course.
2013/12/5 Kai Tietz :
> Nice catch. This describes at least the runtime-failure we got reported.
> Did you tested regressions for this patch?
I have. All tests from tests_pthread pass.
2013/12/5
A few thoughts:
1) Shouldn't global_lock be __LONG32?
2) Would it make sense for the exchange on global_lock to be done as a
single operation (ie InterlockedCompareExchange)?
dw
On 12/5/2013 10:45 AM, Fanael Linithien wrote:
I came up with a patch that fixes the issue for me.
The patch repl
2013/12/5 Fanael Linithien :
> I came up with a patch that fixes the issue for me.
>
> The patch replaces the global critical section with a spinlock.
> Critical sections require explicit initialization before use, which in
> this case is not possible: register_frame_ctor (from libgcc), which
> run
I came up with a patch that fixes the issue for me.
The patch replaces the global critical section with a spinlock.
Critical sections require explicit initialization before use, which in
this case is not possible: register_frame_ctor (from libgcc), which
runs BEFORE enter_global_cs, tries to lock
Alexey Pavlov 2013-11-28 11:35:
> Hi, all!
>
> I'm have issue with winpthreads from trunk rev.6367 and later. It
> break for me dwarf toolchains with threads=posix. Most generated
> binaries with this toolchain crash on startup.
> For example, I build sqlite3 and winpthreads rev.6367 with debuginf
I dont know how to build. I always use CMake to create makefiles without
mysys.
Do I need mysys? where do I get configure?
- Original Message -
From: "JonY"
To:
Sent: Wednesday, November 27, 2013 11:10 PM
Subject: Re: [Mingw-w64-public] winpth
Hi, all!
I'm have issue with winpthreads from trunk rev.6367 and later. It
break for me dwarf toolchains with threads=posix. Most generated
binaries with this toolchain crash on startup.
For example, I build sqlite3 and winpthreads rev.6367 with debuginfo
and has next GDB backtrace http://pastebin
On 11/28/2013 04:33, Ruben Van Boxem wrote:
> 2013/11/27 Jon
>
>>
>>
>>>
>>> Also: Where should I get the sources for winpthreads?
>>>
>>>
>>
>> http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-libraries/winpthreads/
>>
>
> winpthreads had an official release with 3.0.0. No need
2013/11/27 Jon
>
>
>>
>> Also: Where should I get the sources for winpthreads?
>>
>>
>
> http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-libraries/winpthreads/
>
winpthreads had an official release with 3.0.0. No need for development
versions anymore.
Ruben
>
>
> ---
>
> Also: Where should I get the sources for winpthreads?
>
>
http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-libraries/winpthreads/
--
Rapidly troubleshoot problems before they affect your business. Most
Hello
I am setting pthread_setcanceltype( PTHREAD_CANCEL_ASYNCHRONOUS, NULL); in a
thread in order to kill but it does not work
althought in win32 we could use TerminateThread. Any thoughts?
Also: Where should I get the sources for winpthreads?
Best
victor
On Sun, Apr 14, 2013 at 9:09 AM, LRN wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 14.04.2013 10:54, LRN wrote:
>> This patch should integrate the testsuite imported from pthreads
>> with winpthreads. (includes re-generated configure and Makefile.in
>> - it is very sad that those
have a cpu monitor, and taskmgr.exe can
you can add a column for numthreads per process.
>
> From: LRN
>To: mingw-w64-public@lists.sourceforge.net
>Sent: Sunday, April 14, 2013 9:48 AM
>Subject: Re: [Mingw-w64-public] winpthreads testsuite
May be related to openmp hang that I have reported earlier on this list. I
can repost the example if needed.
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14.04.2013 20:25, K. Frank wrote:
> Hi LRN!
>
> On Sun, Apr 14, 2013 at 10:16 AM, LRN <> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 14.04.2013 17:55, K. Frank wrote:
>>> Hello LRN!
>>>
>>> On Sun, Apr 14, 2013 at 2:54 AM, LR
Hi LRN!
On Sun, Apr 14, 2013 at 10:16 AM, LRN <> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 14.04.2013 17:55, K. Frank wrote:
>> Hello LRN!
>>
>> On Sun, Apr 14, 2013 at 2:54 AM, LRN <...> wrote:
>>> ... This patch should integrate the testsuite imported from
>>> pthreads with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14.04.2013 17:55, K. Frank wrote:
> Hello LRN!
>
> On Sun, Apr 14, 2013 at 2:54 AM, LRN <...> wrote:
>> ... This patch should integrate the testsuite imported from
>> pthreads with winpthreads. ...
>
> Did you ever learn more about / sort out the
Hello LRN!
On Sun, Apr 14, 2013 at 2:54 AM, LRN <...> wrote:
> ...
> This patch should integrate the testsuite imported from pthreads with
> winpthreads.
> ...
Did you ever learn more about / sort out the create / join race
condition you reported earlier?
(Sorry to semi-hijack the current threa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14.04.2013 10:54, LRN wrote:
> This patch should integrate the testsuite imported from pthreads
> with winpthreads. (includes re-generated configure and Makefile.in
> - it is very sad that those are tracked in SVN).
>
OK, here is a better patch -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This patch should integrate the testsuite imported from pthreads with
winpthreads.
(includes re-generated configure and Makefile.in - it is very sad that
those are tracked in SVN).
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment:
2012/7/18 Ozkan Sezer:
> Some very small C program showing the brokenness without
> the change, and showing the healthiness with the change applied.
> The existing tests in winpthreads are examples.
>
Test for patch for pthread_getspecific().
Without the patch, main() return -2.
#include
struct
On Wed, Jul 18, 2012 at 2:02 PM, niXman wrote:
> 2012/7/18 Kai Tietz:
>>
>> I applied the patch at rev 5235. But I still wait for the testcase.
>
> What do you mean by the word "testcase"?
> In the previous message I put a logfile with winpthreads test.
>
Some very small C program showing the br
2012/7/18 Kai Tietz:
>
> I applied the patch at rev 5235. But I still wait for the testcase.
What do you mean by the word "testcase"?
In the previous message I put a logfile with winpthreads test.
--
Regards,
niXman
___
Dual-target(32 & 64 bit) M
2012/7/18 niXman :
> 2012/7/17 niXman:
>> 2012/7/16 Kai Tietz:
>>>
>>> So patch is ok with a testcase.
>>
>> Log in attachment.
>
> ping?
I applied the patch at rev 5235. But I still wait for the testcase.
Cheers,
Kai
-
2012/7/17 niXman:
> 2012/7/16 Kai Tietz:
>>
>> So patch is ok with a testcase.
>
> Log in attachment.
ping?
--
Regards,
niXman
___
Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows:
http://sourceforge.net/projects/mingwbuilds/
--
2012/7/16 Kai Tietz:
> Well,
>
> I am fine by this patch, but I would love to get additional a testcase
> added for it.
>
> So patch is ok with a testcase.
Log in attachment.
--
Regards,
niXman
___
Dual-target(32 & 64 bit) MinGW compilers for 32
We also experience an issue with boost::filesystem::exists in blender. If
this fixes that it will be a blessing :).
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
thre
Well,
I am fine by this patch, but I would love to get additional a testcase
added for it.
So patch is ok with a testcase.
Thanks,
Kai
--
Live Security Virtual Conference
Exclusive live event will cover all the ways tod
2012/7/16 niXman
> 2012/7/16 Ozkan Sezer:
>
> > This was discussed quite some time ago and the suggested changes
> > look OK to me at first glance. As a reference, pthreads-win32 restores
> > the last error for pthread_getspecific() (but not for
> pthread_setspecific()
> > as far as I can see.)
>
2012/7/16 Ozkan Sezer:
> This was discussed quite some time ago and the suggested changes
> look OK to me at first glance. As a reference, pthreads-win32 restores
> the last error for pthread_getspecific() (but not for pthread_setspecific()
> as far as I can see.)
Without the restoration of the l
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_s
Patch in attachment.
--
Regards,
niXman
___
Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows:
http://sourceforge.net/projects/mingwbuilds/
winpthreads_lasterror.patch
Description: Binary data
-
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 beca
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 a
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
>>> $ .
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 ple
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?
>> 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 unde
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
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 sai
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 othe
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.
>
>
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 mus
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:
201
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_ * fun
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. Che
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_ *
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. Che
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.
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.
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 easi
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
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_* f
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 on
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+
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 pth
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 f
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
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?
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
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
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_de
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_ti
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
>
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 installi
1 - 100 of 127 matches
Mail list logo
