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?

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
 wrote:
> Fine with me.
>
> Best,
> Mike
>
> On Mar 19, 2017 10:32 AM, "Steven Yi"  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?
>>