[Csnd-dev] Mingw64 no-pthread issue (cond vars)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Csnd-dev] Mingw64 no-pthread issue (cond vars)

Steven Yi
Hi All,

I came across an interesting issue today. It looks like mingw-w64 has
a problem mentioned in:

https://github.com/Alexpux/mingw-w64/pull/2

that does not seem to be addressed upstream.  The current no-pthreads
branch was updated to use Windows' native thread API, which compiles
fine with Visual Studio.  However, when compiling with mingw64, I get:

CMakeFiles/csound64.dir/objects.a(threads.c.obj): In function
`csoundCreateBarrier':
C:/msys64/home/stevenyi/work/csound/no-pthreads/Top/threads.c:238:
undefined reference to `InitializeSynchronizationBarrier'
CMakeFiles/csound64.dir/objects.a(threads.c.obj): In function
`csoundDestroyBarrier':
C:/msys64/home/stevenyi/work/csound/no-pthreads/Top/threads.c:244:
undefined reference to `DeleteSynchronizationBarrier'
CMakeFiles/csound64.dir/objects.a(threads.c.obj): In function
`csoundWaitBarrier':
C:/msys64/home/stevenyi/work/csound/no-pthreads/Top/threads.c:250:
undefined reference to `EnterSynchronizationBarrier'

This seems to be a reported issue for mingw-w64:

https://sourceforge.net/p/mingw-w64/bugs/562/

which I've commented on.  I suspect there won't be a change anytime
soon and that there aren't any workarounds, but I'm not sure. In the
meanwhile, what I think could work is if we modify threads.c to first
check for HAVE_PTHREADS, to use that (which, when compiling with
mingw, we would then use), and if not, to fallback to Microsoft's API
on Windows.  This seems like it would work when compiling with Visual
Studio as we'd ensure HAVE_PTHREADS is not defined, but it would then
require pthreads when compiling with mingw.  This seems fine to me, as
requiring pthreads with mingw is the current behavior in
develop/master.

Does this sound reasonable to everyone?

steven
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Csnd-dev] Mingw64 no-pthread issue (cond vars)

Michael Gogins-2
Fine with me. 

Best, 
Mike

On Mar 19, 2017 10:32 AM, "Steven Yi" <[hidden email]> wrote:
Hi All,

I came across an interesting issue today. It looks like mingw-w64 has
a problem mentioned in:

https://github.com/Alexpux/mingw-w64/pull/2

that does not seem to be addressed upstream.  The current no-pthreads
branch was updated to use Windows' native thread API, which compiles
fine with Visual Studio.  However, when compiling with mingw64, I get:

CMakeFiles/csound64.dir/objects.a(threads.c.obj): In function
`csoundCreateBarrier':
C:/msys64/home/stevenyi/work/csound/no-pthreads/Top/threads.c:238:
undefined reference to `InitializeSynchronizationBarrier'
CMakeFiles/csound64.dir/objects.a(threads.c.obj): In function
`csoundDestroyBarrier':
C:/msys64/home/stevenyi/work/csound/no-pthreads/Top/threads.c:244:
undefined reference to `DeleteSynchronizationBarrier'
CMakeFiles/csound64.dir/objects.a(threads.c.obj): In function
`csoundWaitBarrier':
C:/msys64/home/stevenyi/work/csound/no-pthreads/Top/threads.c:250:
undefined reference to `EnterSynchronizationBarrier'

This seems to be a reported issue for mingw-w64:

https://sourceforge.net/p/mingw-w64/bugs/562/

which I've commented on.  I suspect there won't be a change anytime
soon and that there aren't any workarounds, but I'm not sure. In the
meanwhile, what I think could work is if we modify threads.c to first
check for HAVE_PTHREADS, to use that (which, when compiling with
mingw, we would then use), and if not, to fallback to Microsoft's API
on Windows.  This seems like it would work when compiling with Visual
Studio as we'd ensure HAVE_PTHREADS is not defined, but it would then
require pthreads when compiling with mingw.  This seems fine to me, as
requiring pthreads with mingw is the current behavior in
develop/master.

Does this sound reasonable to everyone?

steven
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Csnd-dev] Mingw64 no-pthread issue (cond vars)

Steven Yi
Thanks for the feedback Michael, I'll plan to move forward with this today.

On Sat, Mar 18, 2017 at 8:01 PM, Michael Gogins
<[hidden email]> wrote:

> Fine with me.
>
> Best,
> Mike
>
> On Mar 19, 2017 10:32 AM, "Steven Yi" <[hidden email]> wrote:
>>
>> Hi All,
>>
>> I came across an interesting issue today. It looks like mingw-w64 has
>> a problem mentioned in:
>>
>> https://github.com/Alexpux/mingw-w64/pull/2
>>
>> that does not seem to be addressed upstream.  The current no-pthreads
>> branch was updated to use Windows' native thread API, which compiles
>> fine with Visual Studio.  However, when compiling with mingw64, I get:
>>
>> CMakeFiles/csound64.dir/objects.a(threads.c.obj): In function
>> `csoundCreateBarrier':
>> C:/msys64/home/stevenyi/work/csound/no-pthreads/Top/threads.c:238:
>> undefined reference to `InitializeSynchronizationBarrier'
>> CMakeFiles/csound64.dir/objects.a(threads.c.obj): In function
>> `csoundDestroyBarrier':
>> C:/msys64/home/stevenyi/work/csound/no-pthreads/Top/threads.c:244:
>> undefined reference to `DeleteSynchronizationBarrier'
>> CMakeFiles/csound64.dir/objects.a(threads.c.obj): In function
>> `csoundWaitBarrier':
>> C:/msys64/home/stevenyi/work/csound/no-pthreads/Top/threads.c:250:
>> undefined reference to `EnterSynchronizationBarrier'
>>
>> This seems to be a reported issue for mingw-w64:
>>
>> https://sourceforge.net/p/mingw-w64/bugs/562/
>>
>> which I've commented on.  I suspect there won't be a change anytime
>> soon and that there aren't any workarounds, but I'm not sure. In the
>> meanwhile, what I think could work is if we modify threads.c to first
>> check for HAVE_PTHREADS, to use that (which, when compiling with
>> mingw, we would then use), and if not, to fallback to Microsoft's API
>> on Windows.  This seems like it would work when compiling with Visual
>> Studio as we'd ensure HAVE_PTHREADS is not defined, but it would then
>> require pthreads when compiling with mingw.  This seems fine to me, as
>> requiring pthreads with mingw is the current behavior in
>> develop/master.
>>
>> Does this sound reasonable to everyone?
>>
>> steven
Loading...