Hi All,

I just pulled the latest and I'm getting a CMake build problem now:

CMake Error at Opcodes/stk/CMakeLists.txt:25 (set_target_properties):
  set_target_properties called with incorrect number of arguments.

I'm using Cmake 3.4.1.  Any ideas?

Yes. Set the value of STK_STATIC_LIBRARY on the CMake command line to
point to your system's static STK library.You should do the same for
PTHREAD_STATIC_LIBRARY.

This is due to a workaround for not obtaining a build of stkops.dll
that links statically to libstk.a. On my system, in spite of
instructions to the contrary, the value of STK_STATIC_LIBRARY is
reverted by CMake to -lstk no matter what I do... which then results
in linking to libstk.dll...  except for this fix, which brings the STK
static library into CMake as an "imported" library.

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Sat, Apr 23, 2016 at 7:05 PM, Steven Yi  wrote:
> Hi All,
>
> I just pulled the latest and I'm getting a CMake build problem now:
>
> CMake Error at Opcodes/stk/CMakeLists.txt:25 (set_target_properties):
>   set_target_properties called with incorrect number of arguments.
>
> I'm using Cmake 3.4.1.  Any ideas?
>

Not msys2 but mingw64. Msys2 is the shell and does include some system
libraries. mingw64 is the development toolchain and includes most
libraries including the Windows runtime libraries and libraries
installed as part of packages by pacman.

With pacman if you install a package, it amost always comes with both
static and dynamic versions of the libraries in the package. But it
can be tricky to convince CMake to use the static version of the
library, that is what this has all been about.

Best,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Sun, Apr 24, 2016 at 2:39 AM, Rory Walsh  wrote:
> Where did you get the static pthread library? Does one come msys2 or can we
> use pacman to get it?
>
> On 24 April 2016 at 00:29, Michael Gogins  wrote:
>>
>> Yes. Set the value of STK_STATIC_LIBRARY on the CMake command line to
>> point to your system's static STK library.You should do the same for
>> PTHREAD_STATIC_LIBRARY.
>>
>> This is due to a workaround for not obtaining a build of stkops.dll
>> that links statically to libstk.a. On my system, in spite of
>> instructions to the contrary, the value of STK_STATIC_LIBRARY is
>> reverted by CMake to -lstk no matter what I do... which then results
>> in linking to libstk.dll...  except for this fix, which brings the STK
>> static library into CMake as an "imported" library.
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Sat, Apr 23, 2016 at 7:05 PM, Steven Yi  wrote:
>> > Hi All,
>> >
>> > I just pulled the latest and I'm getting a CMake build problem now:
>> >
>> > CMake Error at Opcodes/stk/CMakeLists.txt:25 (set_target_properties):
>> >   set_target_properties called with incorrect number of arguments.
>> >
>> > I'm using Cmake 3.4.1.  Any ideas?
>> >
>> > steven
>

I understand it's a workaround but, IMO, the build system has gotten
worse as I now can not build at all because some value isn't set. It
feels like the wrong solution.

On Sat, Apr 23, 2016 at 7:29 PM, Michael Gogins
 wrote:
> Yes. Set the value of STK_STATIC_LIBRARY on the CMake command line to
> point to your system's static STK library.You should do the same for
> PTHREAD_STATIC_LIBRARY.
>
> This is due to a workaround for not obtaining a build of stkops.dll
> that links statically to libstk.a. On my system, in spite of
> instructions to the contrary, the value of STK_STATIC_LIBRARY is
> reverted by CMake to -lstk no matter what I do... which then results
> in linking to libstk.dll...  except for this fix, which brings the STK
> static library into CMake as an "imported" library.
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Sat, Apr 23, 2016 at 7:05 PM, Steven Yi  wrote:
>> Hi All,
>>
>> I just pulled the latest and I'm getting a CMake build problem now:
>>
>> CMake Error at Opcodes/stk/CMakeLists.txt:25 (set_target_properties):
>>   set_target_properties called with incorrect number of arguments.
>>
>> I'm using Cmake 3.4.1.  Any ideas?
>>

I spent several days on this, researched it thoroughly, found that
other people had similar problems, and discovered this workaround,
which is the only solution that appears to work in all cases. I am
done with this for now. If you can find a better solution, I'll be
happy to adopt it. In the meantime, I will update the build
instructions and build.sh to reflect the workaround.

Just to be clear, the goal here is for CMake and mingw64 to link all
Csound plugins with only static library dependencies, in order to
satisfy the requirements of Rory Walsh and other developers of Csound
front ends.

The problem is that even though the build.sh or build-mkg.sh scripts
specify static versions of the pthread and stk libraries, when the
makefile actually runs, CMake goes ahead and translates the
user-specified pathnames from e.g.
-DPTHREAD_LIBRARY:FILEPATH=/mingw64/x86_64-w64-mingw32/lib/libpthread.a
(which is correct) to -lstk, and even with -Wl, -Bstatic -lstk, the
dynamic version of the library seems to be what is used.

I repeat, I fiddled with every way of doing this and only the
workaround of importing the library from a CMake variable specifying
the pathname for the static library works in all cases.

In the meantime, I removed the STK_STATIC_LIBRARY and
PTHREAD_STATIC_LIBRARY variables from the build files. The build
should succeed without specifying the pathnames to static libraries,
but if you don't, then these plugins will get dynamically linked.

Best,
Mike



-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Sun, Apr 24, 2016 at 1:06 PM, Steven Yi  wrote:
> I understand it's a workaround but, IMO, the build system has gotten
> worse as I now can not build at all because some value isn't set. It
> feels like the wrong solution.
>
> On Sat, Apr 23, 2016 at 7:29 PM, Michael Gogins
>  wrote:
>> Yes. Set the value of STK_STATIC_LIBRARY on the CMake command line to
>> point to your system's static STK library.You should do the same for
>> PTHREAD_STATIC_LIBRARY.
>>
>> This is due to a workaround for not obtaining a build of stkops.dll
>> that links statically to libstk.a. On my system, in spite of
>> instructions to the contrary, the value of STK_STATIC_LIBRARY is
>> reverted by CMake to -lstk no matter what I do... which then results
>> in linking to libstk.dll...  except for this fix, which brings the STK
>> static library into CMake as an "imported" library.
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Sat, Apr 23, 2016 at 7:05 PM, Steven Yi  wrote:
>>> Hi All,
>>>
>>> I just pulled the latest and I'm getting a CMake build problem now:
>>>
>>> CMake Error at Opcodes/stk/CMakeLists.txt:25 (set_target_properties):
>>>   set_target_properties called with incorrect number of arguments.
>>>
>>> I'm using Cmake 3.4.1.  Any ideas?
>>>

Sure, I understand this is a tricky problem and appreciate the time
spent on it. However, my problem was that the build went from building
what it could and not building what it couldn't, to not building at
all without intervention.  The latest changes you made restored being
to build here (well, I still have to manually turn off building Csound
AC because of music xml, which is hardcoded in the build.sh to a
location I do not have...). I'd ask that for any future changes, if
they do require some kind of manual intervention to enable building a
target, then they should gracefully disable building that target if
the manual intervention is not done so that the rest of the build
continues to function.



On Sun, Apr 24, 2016 at 3:38 PM, Michael Gogins
 wrote:
> I spent several days on this, researched it thoroughly, found that
> other people had similar problems, and discovered this workaround,
> which is the only solution that appears to work in all cases. I am
> done with this for now. If you can find a better solution, I'll be
> happy to adopt it. In the meantime, I will update the build
> instructions and build.sh to reflect the workaround.
>
> Just to be clear, the goal here is for CMake and mingw64 to link all
> Csound plugins with only static library dependencies, in order to
> satisfy the requirements of Rory Walsh and other developers of Csound
> front ends.
>
> The problem is that even though the build.sh or build-mkg.sh scripts
> specify static versions of the pthread and stk libraries, when the
> makefile actually runs, CMake goes ahead and translates the
> user-specified pathnames from e.g.
> -DPTHREAD_LIBRARY:FILEPATH=/mingw64/x86_64-w64-mingw32/lib/libpthread.a
> (which is correct) to -lstk, and even with -Wl, -Bstatic -lstk, the
> dynamic version of the library seems to be what is used.
>
> I repeat, I fiddled with every way of doing this and only the
> workaround of importing the library from a CMake variable specifying
> the pathname for the static library works in all cases.
>
> In the meantime, I removed the STK_STATIC_LIBRARY and
> PTHREAD_STATIC_LIBRARY variables from the build files. The build
> should succeed without specifying the pathnames to static libraries,
> but if you don't, then these plugins will get dynamically linked.
>
> Best,
> Mike
>
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Sun, Apr 24, 2016 at 1:06 PM, Steven Yi  wrote:
>> I understand it's a workaround but, IMO, the build system has gotten
>> worse as I now can not build at all because some value isn't set. It
>> feels like the wrong solution.
>>
>> On Sat, Apr 23, 2016 at 7:29 PM, Michael Gogins
>>  wrote:
>>> Yes. Set the value of STK_STATIC_LIBRARY on the CMake command line to
>>> point to your system's static STK library.You should do the same for
>>> PTHREAD_STATIC_LIBRARY.
>>>
>>> This is due to a workaround for not obtaining a build of stkops.dll
>>> that links statically to libstk.a. On my system, in spite of
>>> instructions to the contrary, the value of STK_STATIC_LIBRARY is
>>> reverted by CMake to -lstk no matter what I do... which then results
>>> in linking to libstk.dll...  except for this fix, which brings the STK
>>> static library into CMake as an "imported" library.
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Sat, Apr 23, 2016 at 7:05 PM, Steven Yi  wrote:
>>>> Hi All,
>>>>
>>>> I just pulled the latest and I'm getting a CMake build problem now:
>>>>
>>>> CMake Error at Opcodes/stk/CMakeLists.txt:25 (set_target_properties):
>>>>   set_target_properties called with incorrect number of arguments.
>>>>
>>>> I'm using Cmake 3.4.1.  Any ideas?
>>>>

I spent some time looking into the static linking issue.  No solution
so far, but one thing I found was that the CMake changes I had done in
the main CmakeLists.txt that searched for the pthread library was
privileging winpthread-1 over pthread.  That code for CMake was a bit
clunky in retrospect (around like 457).  I replaced using:

find_library(PTHREAD_LIBRARY NAMES pthread winpthread-1 pthreadGC2)

which will pick up libpthread.a first (I believe the same one
mentioned by Michael).  However, this causes linker problems when
building libcsound (something about multiple definitions of pthread
functions).  Anyways, I am going to continue looking at this to see if
this is the more proper solution and, if so, how to fix up what is
going on with the linker problems.

On Sun, Apr 24, 2016 at 6:18 PM, Steven Yi  wrote:
> Sure, I understand this is a tricky problem and appreciate the time
> spent on it. However, my problem was that the build went from building
> what it could and not building what it couldn't, to not building at
> all without intervention.  The latest changes you made restored being
> to build here (well, I still have to manually turn off building Csound
> AC because of music xml, which is hardcoded in the build.sh to a
> location I do not have...). I'd ask that for any future changes, if
> they do require some kind of manual intervention to enable building a
> target, then they should gracefully disable building that target if
> the manual intervention is not done so that the rest of the build
> continues to function.
>
>
>
> On Sun, Apr 24, 2016 at 3:38 PM, Michael Gogins
>  wrote:
>> I spent several days on this, researched it thoroughly, found that
>> other people had similar problems, and discovered this workaround,
>> which is the only solution that appears to work in all cases. I am
>> done with this for now. If you can find a better solution, I'll be
>> happy to adopt it. In the meantime, I will update the build
>> instructions and build.sh to reflect the workaround.
>>
>> Just to be clear, the goal here is for CMake and mingw64 to link all
>> Csound plugins with only static library dependencies, in order to
>> satisfy the requirements of Rory Walsh and other developers of Csound
>> front ends.
>>
>> The problem is that even though the build.sh or build-mkg.sh scripts
>> specify static versions of the pthread and stk libraries, when the
>> makefile actually runs, CMake goes ahead and translates the
>> user-specified pathnames from e.g.
>> -DPTHREAD_LIBRARY:FILEPATH=/mingw64/x86_64-w64-mingw32/lib/libpthread.a
>> (which is correct) to -lstk, and even with -Wl, -Bstatic -lstk, the
>> dynamic version of the library seems to be what is used.
>>
>> I repeat, I fiddled with every way of doing this and only the
>> workaround of importing the library from a CMake variable specifying
>> the pathname for the static library works in all cases.
>>
>> In the meantime, I removed the STK_STATIC_LIBRARY and
>> PTHREAD_STATIC_LIBRARY variables from the build files. The build
>> should succeed without specifying the pathnames to static libraries,
>> but if you don't, then these plugins will get dynamically linked.
>>
>> Best,
>> Mike
>>
>>
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Sun, Apr 24, 2016 at 1:06 PM, Steven Yi  wrote:
>>> I understand it's a workaround but, IMO, the build system has gotten
>>> worse as I now can not build at all because some value isn't set. It
>>> feels like the wrong solution.
>>>
>>> On Sat, Apr 23, 2016 at 7:29 PM, Michael Gogins
>>>  wrote:
>>>> Yes. Set the value of STK_STATIC_LIBRARY on the CMake command line to
>>>> point to your system's static STK library.You should do the same for
>>>> PTHREAD_STATIC_LIBRARY.
>>>>
>>>> This is due to a workaround for not obtaining a build of stkops.dll
>>>> that links statically to libstk.a. On my system, in spite of
>>>> instructions to the contrary, the value of STK_STATIC_LIBRARY is
>>>> reverted by CMake to -lstk no matter what I do... which then results
>>>> in linking to libstk.dll...  except for this fix, which brings the STK
>>>> static library into CMake as an "imported" library.
>>>>
>>>> -----------------------------------------------------
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://michaelgogins.tumblr.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>>
>>>> On Sat, Apr 23, 2016 at 7:05 PM, Steven Yi  wrote:
>>>>> Hi All,
>>>>>
>>>>> I just pulled the latest and I'm getting a CMake build problem now:
>>>>>
>>>>> CMake Error at Opcodes/stk/CMakeLists.txt:25 (set_target_properties):
>>>>>   set_target_properties called with incorrect number of arguments.
>>>>>
>>>>> I'm using Cmake 3.4.1.  Any ideas?
>>>>>

Hi All,

So I'm finding some weird behavior.  A couple of email threads ago, I
mentioned being confused about how csound64.dll could be statically
linking to pthreads when libwinpthread-1.dll is found.  After
experimenting with the PTHREAD_LIBRARY NAMES and getting CMake to find
the static libpthread.a, I was getting errors about multiple
definitions.  What I did to get rid of the problem was to remove the
addition of $PTHREAD_LIBRARY to the target_link_libraries for
libcsound.  Oddly, that worked.  What I am speculating is that one of
the flags, perhaps -static-libgcc, is already adding in libpthread.a
internally.  Adding the explicit link afterwards would then cause the
multiple definitions.

Experimenting with that worked for libcsound.  This leaves two
problems here: the osc and stkops opcode libraries.  For osc, if I
remove the use of $PTHREAD_LIBRARY, it will build.  However, ldd will
not show any pthread links, but dependency walker does show a
dependency on libwinpthread-1.  If I copy in the libwinpthread-1, the
osc library will load, but stkops will still fail to load.  With
dependency walker, stkops shows a missing dependency on
libstdc++6.dll, which is odd considering -static-libstdc++ is being
used in linking.  I suspect for both of these, the libraries are
coming in transitively through liblo and libstk.  I will look at
building those packages to use static-libgcc or static-libc++ next.

steven

On Mon, Apr 25, 2016 at 10:33 PM, Steven Yi  wrote:
> I spent some time looking into the static linking issue.  No solution
> so far, but one thing I found was that the CMake changes I had done in
> the main CmakeLists.txt that searched for the pthread library was
> privileging winpthread-1 over pthread.  That code for CMake was a bit
> clunky in retrospect (around like 457).  I replaced using:
>
> find_library(PTHREAD_LIBRARY NAMES pthread winpthread-1 pthreadGC2)
>
> which will pick up libpthread.a first (I believe the same one
> mentioned by Michael).  However, this causes linker problems when
> building libcsound (something about multiple definitions of pthread
> functions).  Anyways, I am going to continue looking at this to see if
> this is the more proper solution and, if so, how to fix up what is
> going on with the linker problems.
>
> On Sun, Apr 24, 2016 at 6:18 PM, Steven Yi  wrote:
>> Sure, I understand this is a tricky problem and appreciate the time
>> spent on it. However, my problem was that the build went from building
>> what it could and not building what it couldn't, to not building at
>> all without intervention.  The latest changes you made restored being
>> to build here (well, I still have to manually turn off building Csound
>> AC because of music xml, which is hardcoded in the build.sh to a
>> location I do not have...). I'd ask that for any future changes, if
>> they do require some kind of manual intervention to enable building a
>> target, then they should gracefully disable building that target if
>> the manual intervention is not done so that the rest of the build
>> continues to function.
>>
>>
>>
>> On Sun, Apr 24, 2016 at 3:38 PM, Michael Gogins
>>  wrote:
>>> I spent several days on this, researched it thoroughly, found that
>>> other people had similar problems, and discovered this workaround,
>>> which is the only solution that appears to work in all cases. I am
>>> done with this for now. If you can find a better solution, I'll be
>>> happy to adopt it. In the meantime, I will update the build
>>> instructions and build.sh to reflect the workaround.
>>>
>>> Just to be clear, the goal here is for CMake and mingw64 to link all
>>> Csound plugins with only static library dependencies, in order to
>>> satisfy the requirements of Rory Walsh and other developers of Csound
>>> front ends.
>>>
>>> The problem is that even though the build.sh or build-mkg.sh scripts
>>> specify static versions of the pthread and stk libraries, when the
>>> makefile actually runs, CMake goes ahead and translates the
>>> user-specified pathnames from e.g.
>>> -DPTHREAD_LIBRARY:FILEPATH=/mingw64/x86_64-w64-mingw32/lib/libpthread.a
>>> (which is correct) to -lstk, and even with -Wl, -Bstatic -lstk, the
>>> dynamic version of the library seems to be what is used.
>>>
>>> I repeat, I fiddled with every way of doing this and only the
>>> workaround of importing the library from a CMake variable specifying
>>> the pathname for the static library works in all cases.
>>>
>>> In the meantime, I removed the STK_STATIC_LIBRARY and
>>> PTHREAD_STATIC_LIBRARY variables from the build files. The build
>>> should succeed without specifying the pathnames to static libraries,
>>> but if you don't, then these plugins will get dynamically linked.
>>>
>>> Best,
>>> Mike
>>>
>>>
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Sun, Apr 24, 2016 at 1:06 PM, Steven Yi  wrote:
>>>> I understand it's a workaround but, IMO, the build system has gotten
>>>> worse as I now can not build at all because some value isn't set. It
>>>> feels like the wrong solution.
>>>>
>>>> On Sat, Apr 23, 2016 at 7:29 PM, Michael Gogins
>>>>  wrote:
>>>>> Yes. Set the value of STK_STATIC_LIBRARY on the CMake command line to
>>>>> point to your system's static STK library.You should do the same for
>>>>> PTHREAD_STATIC_LIBRARY.
>>>>>
>>>>> This is due to a workaround for not obtaining a build of stkops.dll
>>>>> that links statically to libstk.a. On my system, in spite of
>>>>> instructions to the contrary, the value of STK_STATIC_LIBRARY is
>>>>> reverted by CMake to -lstk no matter what I do... which then results
>>>>> in linking to libstk.dll...  except for this fix, which brings the STK
>>>>> static library into CMake as an "imported" library.
>>>>>
>>>>> -----------------------------------------------------
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://michaelgogins.tumblr.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>>
>>>>> On Sat, Apr 23, 2016 at 7:05 PM, Steven Yi  wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> I just pulled the latest and I'm getting a CMake build problem now:
>>>>>>
>>>>>> CMake Error at Opcodes/stk/CMakeLists.txt:25 (set_target_properties):
>>>>>>   set_target_properties called with incorrect number of arguments.
>>>>>>
>>>>>> I'm using Cmake 3.4.1.  Any ideas?
>>>>>>

Finder scripts are great but it's not going to solve whether to add
$PTHREAD_LIBRARY or not.  We still need to verify threads exist but I
think we don't want to explicitly link to it on Windows if, as I
speculated, -static-libgcc brings that in automatically.

What I'm seeing seems to support a different conclusion for the other
libraries. For example, I do see the use of -lstk instead of a full
path, but it is happening after a -Wl,-Bstatic flag.  So despite the
short lib name, I am still getting static links, as is shown with
dependency walker and ldd.  However, it is the two other libraries,
libwinpthread-1 and libstdc++6.dll, that are coming in somehow.
That's what I haven't understood yet.

On Tue, Apr 26, 2016 at 11:13 AM, Michael Gogins
 wrote:
> The canonical approach is to write a FindXXX.cmake to encapsulate this logic
> and make it reusable by making it possible to call find_package. I suggest
> we write a FindPTHREAD.cmake. As a result of not doing this for many
> dependencies, our build system has become unnecessarily messy.
>
> However, doing this will still not solve the static linkage problem, which
> is caused by CMake not using the library pathname it has been given, not
> even if it is the full pathname, unless that pathname is a string literal
> passed to target_link_libraries, or my import library workaround is used.
>
> Best,
> Mike
>
> I spent some time looking into the static linking issue.  No solution
> so far, but one thing I found was that the CMake changes I had done in
> the main CmakeLists.txt that searched for the pthread library was
> privileging winpthread-1 over pthread.  That code for CMake was a bit
> clunky in retrospect (around like 457).  I replaced using:
>
> find_library(PTHREAD_LIBRARY NAMES pthread winpthread-1 pthreadGC2)
>
> which will pick up libpthread.a first (I believe the same one
> mentioned by Michael).  However, this causes linker problems when
> building libcsound (something about multiple definitions of pthread
> functions).  Anyways, I am going to continue looking at this to see if
> this is the more proper solution and, if so, how to fix up what is
> going on with the linker problems.
>
> On Sun, Apr 24, 2016 at 6:18 PM, Steven Yi  wrote:
>> Sure, I understand this is a tricky problem and appreciate the time
>> spent on it. However, my problem was that the build went from building
>> what it could and not building what it couldn't, to not building at
>> all without intervention.  The latest changes you made restored being
>> to build here (well, I still have to manually turn off building Csound
>> AC because of music xml, which is hardcoded in the build.sh to a
>> location I do not have...). I'd ask that for any future changes, if
>> they do require some kind of manual intervention to enable building a
>> target, then they should gracefully disable building that target if
>> the manual intervention is not done so that the rest of the build
>> continues to function.
>>
>>
>>
>> On Sun, Apr 24, 2016 at 3:38 PM, Michael Gogins
>>  wrote:
>>> I spent several days on this, researched it thoroughly, found that
>>> other people had similar problems, and discovered this workaround,
>>> which is the only solution that appears to work in all cases. I am
>>> done with this for now. If you can find a better solution, I'll be
>>> happy to adopt it. In the meantime, I will update the build
>>> instructions and build.sh to reflect the workaround.
>>>
>>> Just to be clear, the goal here is for CMake and mingw64 to link all
>>> Csound plugins with only static library dependencies, in order to
>>> satisfy the requirements of Rory Walsh and other developers of Csound
>>> front ends.
>>>
>>> The problem is that even though the build.sh or build-mkg.sh scripts
>>> specify static versions of the pthread and stk libraries, when the
>>> makefile actually runs, CMake goes ahead and translates the
>>> user-specified pathnames from e.g.
>>> -DPTHREAD_LIBRARY:FILEPATH=/mingw64/x86_64-w64-mingw32/lib/libpthread.a
>>> (which is correct) to -lstk, and even with -Wl, -Bstatic -lstk, the
>>> dynamic version of the library seems to be what is used.
>>>
>>> I repeat, I fiddled with every way of doing this and only the
>>> workaround of importing the library from a CMake variable specifying
>>> the pathname for the static library works in all cases.
>>>
>>> In the meantime, I removed the STK_STATIC_LIBRARY and
>>> PTHREAD_STATIC_LIBRARY variables from the build files. The build
>>> should succeed without specifying the pathnames to static libraries,
>>> but if you don't, then these plugins will get dynamically linked.
>>>
>>> Best,
>>> Mike
>>>
>>>
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Sun, Apr 24, 2016 at 1:06 PM, Steven Yi  wrote:
>>>> I understand it's a workaround but, IMO, the build system has gotten
>>>> worse as I now can not build at all because some value isn't set. It
>>>> feels like the wrong solution.
>>>>
>>>> On Sat, Apr 23, 2016 at 7:29 PM, Michael Gogins
>>>>  wrote:
>>>>> Yes. Set the value of STK_STATIC_LIBRARY on the CMake command line to
>>>>> point to your system's static STK library.You should do the same for
>>>>> PTHREAD_STATIC_LIBRARY.
>>>>>
>>>>> This is due to a workaround for not obtaining a build of stkops.dll
>>>>> that links statically to libstk.a. On my system, in spite of
>>>>> instructions to the contrary, the value of STK_STATIC_LIBRARY is
>>>>> reverted by CMake to -lstk no matter what I do... which then results
>>>>> in linking to libstk.dll...  except for this fix, which brings the STK
>>>>> static library into CMake as an "imported" library.
>>>>>
>>>>> -----------------------------------------------------
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://michaelgogins.tumblr.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>>
>>>>> On Sat, Apr 23, 2016 at 7:05 PM, Steven Yi  wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> I just pulled the latest and I'm getting a CMake build problem now:
>>>>>>
>>>>>> CMake Error at Opcodes/stk/CMakeLists.txt:25 (set_target_properties):
>>>>>>   set_target_properties called with incorrect number of arguments.
>>>>>>
>>>>>> I'm using Cmake 3.4.1.  Any ideas?
>>>>>>

Just FYI, I continued to look into this but have not found a sensible
cause yet.  I did also try installing clang and building with that.
That seems to have a different set of problems with pthread linking.
I will continue to look into this.

On Tue, Apr 26, 2016 at 11:22 AM, Steven Yi  wrote:
> Finder scripts are great but it's not going to solve whether to add
> $PTHREAD_LIBRARY or not.  We still need to verify threads exist but I
> think we don't want to explicitly link to it on Windows if, as I
> speculated, -static-libgcc brings that in automatically.
>
> What I'm seeing seems to support a different conclusion for the other
> libraries. For example, I do see the use of -lstk instead of a full
> path, but it is happening after a -Wl,-Bstatic flag.  So despite the
> short lib name, I am still getting static links, as is shown with
> dependency walker and ldd.  However, it is the two other libraries,
> libwinpthread-1 and libstdc++6.dll, that are coming in somehow.
> That's what I haven't understood yet.
>
> On Tue, Apr 26, 2016 at 11:13 AM, Michael Gogins
>  wrote:
>> The canonical approach is to write a FindXXX.cmake to encapsulate this logic
>> and make it reusable by making it possible to call find_package. I suggest
>> we write a FindPTHREAD.cmake. As a result of not doing this for many
>> dependencies, our build system has become unnecessarily messy.
>>
>> However, doing this will still not solve the static linkage problem, which
>> is caused by CMake not using the library pathname it has been given, not
>> even if it is the full pathname, unless that pathname is a string literal
>> passed to target_link_libraries, or my import library workaround is used.
>>
>> Best,
>> Mike
>>
>> I spent some time looking into the static linking issue.  No solution
>> so far, but one thing I found was that the CMake changes I had done in
>> the main CmakeLists.txt that searched for the pthread library was
>> privileging winpthread-1 over pthread.  That code for CMake was a bit
>> clunky in retrospect (around like 457).  I replaced using:
>>
>> find_library(PTHREAD_LIBRARY NAMES pthread winpthread-1 pthreadGC2)
>>
>> which will pick up libpthread.a first (I believe the same one
>> mentioned by Michael).  However, this causes linker problems when
>> building libcsound (something about multiple definitions of pthread
>> functions).  Anyways, I am going to continue looking at this to see if
>> this is the more proper solution and, if so, how to fix up what is
>> going on with the linker problems.
>>
>> On Sun, Apr 24, 2016 at 6:18 PM, Steven Yi  wrote:
>>> Sure, I understand this is a tricky problem and appreciate the time
>>> spent on it. However, my problem was that the build went from building
>>> what it could and not building what it couldn't, to not building at
>>> all without intervention.  The latest changes you made restored being
>>> to build here (well, I still have to manually turn off building Csound
>>> AC because of music xml, which is hardcoded in the build.sh to a
>>> location I do not have...). I'd ask that for any future changes, if
>>> they do require some kind of manual intervention to enable building a
>>> target, then they should gracefully disable building that target if
>>> the manual intervention is not done so that the rest of the build
>>> continues to function.
>>>
>>>
>>>
>>> On Sun, Apr 24, 2016 at 3:38 PM, Michael Gogins
>>>  wrote:
>>>> I spent several days on this, researched it thoroughly, found that
>>>> other people had similar problems, and discovered this workaround,
>>>> which is the only solution that appears to work in all cases. I am
>>>> done with this for now. If you can find a better solution, I'll be
>>>> happy to adopt it. In the meantime, I will update the build
>>>> instructions and build.sh to reflect the workaround.
>>>>
>>>> Just to be clear, the goal here is for CMake and mingw64 to link all
>>>> Csound plugins with only static library dependencies, in order to
>>>> satisfy the requirements of Rory Walsh and other developers of Csound
>>>> front ends.
>>>>
>>>> The problem is that even though the build.sh or build-mkg.sh scripts
>>>> specify static versions of the pthread and stk libraries, when the
>>>> makefile actually runs, CMake goes ahead and translates the
>>>> user-specified pathnames from e.g.
>>>> -DPTHREAD_LIBRARY:FILEPATH=/mingw64/x86_64-w64-mingw32/lib/libpthread.a
>>>> (which is correct) to -lstk, and even with -Wl, -Bstatic -lstk, the
>>>> dynamic version of the library seems to be what is used.
>>>>
>>>> I repeat, I fiddled with every way of doing this and only the
>>>> workaround of importing the library from a CMake variable specifying
>>>> the pathname for the static library works in all cases.
>>>>
>>>> In the meantime, I removed the STK_STATIC_LIBRARY and
>>>> PTHREAD_STATIC_LIBRARY variables from the build files. The build
>>>> should succeed without specifying the pathnames to static libraries,
>>>> but if you don't, then these plugins will get dynamically linked.
>>>>
>>>> Best,
>>>> Mike
>>>>
>>>>
>>>>
>>>> -----------------------------------------------------
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://michaelgogins.tumblr.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>>
>>>> On Sun, Apr 24, 2016 at 1:06 PM, Steven Yi  wrote:
>>>>> I understand it's a workaround but, IMO, the build system has gotten
>>>>> worse as I now can not build at all because some value isn't set. It
>>>>> feels like the wrong solution.
>>>>>
>>>>> On Sat, Apr 23, 2016 at 7:29 PM, Michael Gogins
>>>>>  wrote:
>>>>>> Yes. Set the value of STK_STATIC_LIBRARY on the CMake command line to
>>>>>> point to your system's static STK library.You should do the same for
>>>>>> PTHREAD_STATIC_LIBRARY.
>>>>>>
>>>>>> This is due to a workaround for not obtaining a build of stkops.dll
>>>>>> that links statically to libstk.a. On my system, in spite of
>>>>>> instructions to the contrary, the value of STK_STATIC_LIBRARY is
>>>>>> reverted by CMake to -lstk no matter what I do... which then results
>>>>>> in linking to libstk.dll...  except for this fix, which brings the STK
>>>>>> static library into CMake as an "imported" library.
>>>>>>
>>>>>> -----------------------------------------------------
>>>>>> Michael Gogins
>>>>>> Irreducible Productions
>>>>>> http://michaelgogins.tumblr.com
>>>>>> Michael dot Gogins at gmail dot com
>>>>>>
>>>>>>
>>>>>> On Sat, Apr 23, 2016 at 7:05 PM, Steven Yi  wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I just pulled the latest and I'm getting a CMake build problem now:
>>>>>>>
>>>>>>> CMake Error at Opcodes/stk/CMakeLists.txt:25 (set_target_properties):
>>>>>>>   set_target_properties called with incorrect number of arguments.
>>>>>>>
>>>>>>> I'm using Cmake 3.4.1.  Any ideas?
>>>>>>>

Hi All,

I did some further research and I think that something that might be
influencing the odd linking with winpthread-1.dll I'm seeing here is
that the GCC that gets installed via pacman on msys2 uses:

Thread model: posix

(found using 'gcc -v')

Online, it seems like one should have a "Thread model: win32" version
of gcc to compile against -static-libgcc and ensure no
winpthreads-1.dll is pull in.

Most of the text I saw referring to thread models of win32 and msys2
refer to gcc 4.9.x. I am guessing they changed to posix when going to
gcc 5.x.  I'm going to continue looking into this.

steven


On Fri, Apr 29, 2016 at 10:36 AM, Steven Yi  wrote:
> Just FYI, I continued to look into this but have not found a sensible
> cause yet.  I did also try installing clang and building with that.
> That seems to have a different set of problems with pthread linking.
> I will continue to look into this.
>
> On Tue, Apr 26, 2016 at 11:22 AM, Steven Yi  wrote:
>> Finder scripts are great but it's not going to solve whether to add
>> $PTHREAD_LIBRARY or not.  We still need to verify threads exist but I
>> think we don't want to explicitly link to it on Windows if, as I
>> speculated, -static-libgcc brings that in automatically.
>>
>> What I'm seeing seems to support a different conclusion for the other
>> libraries. For example, I do see the use of -lstk instead of a full
>> path, but it is happening after a -Wl,-Bstatic flag.  So despite the
>> short lib name, I am still getting static links, as is shown with
>> dependency walker and ldd.  However, it is the two other libraries,
>> libwinpthread-1 and libstdc++6.dll, that are coming in somehow.
>> That's what I haven't understood yet.
>>
>> On Tue, Apr 26, 2016 at 11:13 AM, Michael Gogins
>>  wrote:
>>> The canonical approach is to write a FindXXX.cmake to encapsulate this logic
>>> and make it reusable by making it possible to call find_package. I suggest
>>> we write a FindPTHREAD.cmake. As a result of not doing this for many
>>> dependencies, our build system has become unnecessarily messy.
>>>
>>> However, doing this will still not solve the static linkage problem, which
>>> is caused by CMake not using the library pathname it has been given, not
>>> even if it is the full pathname, unless that pathname is a string literal
>>> passed to target_link_libraries, or my import library workaround is used.
>>>
>>> Best,
>>> Mike
>>>
>>> I spent some time looking into the static linking issue.  No solution
>>> so far, but one thing I found was that the CMake changes I had done in
>>> the main CmakeLists.txt that searched for the pthread library was
>>> privileging winpthread-1 over pthread.  That code for CMake was a bit
>>> clunky in retrospect (around like 457).  I replaced using:
>>>
>>> find_library(PTHREAD_LIBRARY NAMES pthread winpthread-1 pthreadGC2)
>>>
>>> which will pick up libpthread.a first (I believe the same one
>>> mentioned by Michael).  However, this causes linker problems when
>>> building libcsound (something about multiple definitions of pthread
>>> functions).  Anyways, I am going to continue looking at this to see if
>>> this is the more proper solution and, if so, how to fix up what is
>>> going on with the linker problems.
>>>
>>> On Sun, Apr 24, 2016 at 6:18 PM, Steven Yi  wrote:
>>>> Sure, I understand this is a tricky problem and appreciate the time
>>>> spent on it. However, my problem was that the build went from building
>>>> what it could and not building what it couldn't, to not building at
>>>> all without intervention.  The latest changes you made restored being
>>>> to build here (well, I still have to manually turn off building Csound
>>>> AC because of music xml, which is hardcoded in the build.sh to a
>>>> location I do not have...). I'd ask that for any future changes, if
>>>> they do require some kind of manual intervention to enable building a
>>>> target, then they should gracefully disable building that target if
>>>> the manual intervention is not done so that the rest of the build
>>>> continues to function.
>>>>
>>>>
>>>>
>>>> On Sun, Apr 24, 2016 at 3:38 PM, Michael Gogins
>>>>  wrote:
>>>>> I spent several days on this, researched it thoroughly, found that
>>>>> other people had similar problems, and discovered this workaround,
>>>>> which is the only solution that appears to work in all cases. I am
>>>>> done with this for now. If you can find a better solution, I'll be
>>>>> happy to adopt it. In the meantime, I will update the build
>>>>> instructions and build.sh to reflect the workaround.
>>>>>
>>>>> Just to be clear, the goal here is for CMake and mingw64 to link all
>>>>> Csound plugins with only static library dependencies, in order to
>>>>> satisfy the requirements of Rory Walsh and other developers of Csound
>>>>> front ends.
>>>>>
>>>>> The problem is that even though the build.sh or build-mkg.sh scripts
>>>>> specify static versions of the pthread and stk libraries, when the
>>>>> makefile actually runs, CMake goes ahead and translates the
>>>>> user-specified pathnames from e.g.
>>>>> -DPTHREAD_LIBRARY:FILEPATH=/mingw64/x86_64-w64-mingw32/lib/libpthread.a
>>>>> (which is correct) to -lstk, and even with -Wl, -Bstatic -lstk, the
>>>>> dynamic version of the library seems to be what is used.
>>>>>
>>>>> I repeat, I fiddled with every way of doing this and only the
>>>>> workaround of importing the library from a CMake variable specifying
>>>>> the pathname for the static library works in all cases.
>>>>>
>>>>> In the meantime, I removed the STK_STATIC_LIBRARY and
>>>>> PTHREAD_STATIC_LIBRARY variables from the build files. The build
>>>>> should succeed without specifying the pathnames to static libraries,
>>>>> but if you don't, then these plugins will get dynamically linked.
>>>>>
>>>>> Best,
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>> -----------------------------------------------------
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://michaelgogins.tumblr.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>>
>>>>> On Sun, Apr 24, 2016 at 1:06 PM, Steven Yi  wrote:
>>>>>> I understand it's a workaround but, IMO, the build system has gotten
>>>>>> worse as I now can not build at all because some value isn't set. It
>>>>>> feels like the wrong solution.
>>>>>>
>>>>>> On Sat, Apr 23, 2016 at 7:29 PM, Michael Gogins
>>>>>>  wrote:
>>>>>>> Yes. Set the value of STK_STATIC_LIBRARY on the CMake command line to
>>>>>>> point to your system's static STK library.You should do the same for
>>>>>>> PTHREAD_STATIC_LIBRARY.
>>>>>>>
>>>>>>> This is due to a workaround for not obtaining a build of stkops.dll
>>>>>>> that links statically to libstk.a. On my system, in spite of
>>>>>>> instructions to the contrary, the value of STK_STATIC_LIBRARY is
>>>>>>> reverted by CMake to -lstk no matter what I do... which then results
>>>>>>> in linking to libstk.dll...  except for this fix, which brings the STK
>>>>>>> static library into CMake as an "imported" library.
>>>>>>>
>>>>>>> -----------------------------------------------------
>>>>>>> Michael Gogins
>>>>>>> Irreducible Productions
>>>>>>> http://michaelgogins.tumblr.com
>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Apr 23, 2016 at 7:05 PM, Steven Yi  wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> I just pulled the latest and I'm getting a CMake build problem now:
>>>>>>>>
>>>>>>>> CMake Error at Opcodes/stk/CMakeLists.txt:25 (set_target_properties):
>>>>>>>>   set_target_properties called with incorrect number of arguments.
>>>>>>>>
>>>>>>>> I'm using Cmake 3.4.1.  Any ideas?
>>>>>>>>

It all seems very confusing. How hard would be to build the whole thing with Microsoft tools?

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 2 May 2016, at 20:14, Steven Yi  wrote:
> 
> Hi All,
> 
> I did some further research and I think that something that might be
> influencing the odd linking with winpthread-1.dll I'm seeing here is
> that the GCC that gets installed via pacman on msys2 uses:
> 
> Thread model: posix
> 
> (found using 'gcc -v')
> 
> Online, it seems like one should have a "Thread model: win32" version
> of gcc to compile against -static-libgcc and ensure no
> winpthreads-1.dll is pull in.
> 
> Most of the text I saw referring to thread models of win32 and msys2
> refer to gcc 4.9.x. I am guessing they changed to posix when going to
> gcc 5.x.  I'm going to continue looking into this.
> 
> steven
> 
> 
>> On Fri, Apr 29, 2016 at 10:36 AM, Steven Yi  wrote:
>> Just FYI, I continued to look into this but have not found a sensible
>> cause yet.  I did also try installing clang and building with that.
>> That seems to have a different set of problems with pthread linking.
>> I will continue to look into this.
>> 
>>> On Tue, Apr 26, 2016 at 11:22 AM, Steven Yi  wrote:
>>> Finder scripts are great but it's not going to solve whether to add
>>> $PTHREAD_LIBRARY or not.  We still need to verify threads exist but I
>>> think we don't want to explicitly link to it on Windows if, as I
>>> speculated, -static-libgcc brings that in automatically.
>>> 
>>> What I'm seeing seems to support a different conclusion for the other
>>> libraries. For example, I do see the use of -lstk instead of a full
>>> path, but it is happening after a -Wl,-Bstatic flag.  So despite the
>>> short lib name, I am still getting static links, as is shown with
>>> dependency walker and ldd.  However, it is the two other libraries,
>>> libwinpthread-1 and libstdc++6.dll, that are coming in somehow.
>>> That's what I haven't understood yet.
>>> 
>>> On Tue, Apr 26, 2016 at 11:13 AM, Michael Gogins
>>>  wrote:
>>>> The canonical approach is to write a FindXXX.cmake to encapsulate this logic
>>>> and make it reusable by making it possible to call find_package. I suggest
>>>> we write a FindPTHREAD.cmake. As a result of not doing this for many
>>>> dependencies, our build system has become unnecessarily messy.
>>>> 
>>>> However, doing this will still not solve the static linkage problem, which
>>>> is caused by CMake not using the library pathname it has been given, not
>>>> even if it is the full pathname, unless that pathname is a string literal
>>>> passed to target_link_libraries, or my import library workaround is used.
>>>> 
>>>> Best,
>>>> Mike
>>>> 
>>>> I spent some time looking into the static linking issue.  No solution
>>>> so far, but one thing I found was that the CMake changes I had done in
>>>> the main CmakeLists.txt that searched for the pthread library was
>>>> privileging winpthread-1 over pthread.  That code for CMake was a bit
>>>> clunky in retrospect (around like 457).  I replaced using:
>>>> 
>>>> find_library(PTHREAD_LIBRARY NAMES pthread winpthread-1 pthreadGC2)
>>>> 
>>>> which will pick up libpthread.a first (I believe the same one
>>>> mentioned by Michael).  However, this causes linker problems when
>>>> building libcsound (something about multiple definitions of pthread
>>>> functions).  Anyways, I am going to continue looking at this to see if
>>>> this is the more proper solution and, if so, how to fix up what is
>>>> going on with the linker problems.
>>>> 
>>>>> On Sun, Apr 24, 2016 at 6:18 PM, Steven Yi  wrote:
>>>>> Sure, I understand this is a tricky problem and appreciate the time
>>>>> spent on it. However, my problem was that the build went from building
>>>>> what it could and not building what it couldn't, to not building at
>>>>> all without intervention.  The latest changes you made restored being
>>>>> to build here (well, I still have to manually turn off building Csound
>>>>> AC because of music xml, which is hardcoded in the build.sh to a
>>>>> location I do not have...). I'd ask that for any future changes, if
>>>>> they do require some kind of manual intervention to enable building a
>>>>> target, then they should gracefully disable building that target if
>>>>> the manual intervention is not done so that the rest of the build
>>>>> continues to function.
>>>>> 
>>>>> 
>>>>> 
>>>>> On Sun, Apr 24, 2016 at 3:38 PM, Michael Gogins
>>>>>  wrote:
>>>>>> I spent several days on this, researched it thoroughly, found that
>>>>>> other people had similar problems, and discovered this workaround,
>>>>>> which is the only solution that appears to work in all cases. I am
>>>>>> done with this for now. If you can find a better solution, I'll be
>>>>>> happy to adopt it. In the meantime, I will update the build
>>>>>> instructions and build.sh to reflect the workaround.
>>>>>> 
>>>>>> Just to be clear, the goal here is for CMake and mingw64 to link all
>>>>>> Csound plugins with only static library dependencies, in order to
>>>>>> satisfy the requirements of Rory Walsh and other developers of Csound
>>>>>> front ends.
>>>>>> 
>>>>>> The problem is that even though the build.sh or build-mkg.sh scripts
>>>>>> specify static versions of the pthread and stk libraries, when the
>>>>>> makefile actually runs, CMake goes ahead and translates the
>>>>>> user-specified pathnames from e.g.
>>>>>> -DPTHREAD_LIBRARY:FILEPATH=/mingw64/x86_64-w64-mingw32/lib/libpthread.a
>>>>>> (which is correct) to -lstk, and even with -Wl, -Bstatic -lstk, the
>>>>>> dynamic version of the library seems to be what is used.
>>>>>> 
>>>>>> I repeat, I fiddled with every way of doing this and only the
>>>>>> workaround of importing the library from a CMake variable specifying
>>>>>> the pathname for the static library works in all cases.
>>>>>> 
>>>>>> In the meantime, I removed the STK_STATIC_LIBRARY and
>>>>>> PTHREAD_STATIC_LIBRARY variables from the build files. The build
>>>>>> should succeed without specifying the pathnames to static libraries,
>>>>>> but if you don't, then these plugins will get dynamically linked.
>>>>>> 
>>>>>> Best,
>>>>>> Mike
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -----------------------------------------------------
>>>>>> Michael Gogins
>>>>>> Irreducible Productions
>>>>>> http://michaelgogins.tumblr.com
>>>>>> Michael dot Gogins at gmail dot com
>>>>>> 
>>>>>> 
>>>>>>> On Sun, Apr 24, 2016 at 1:06 PM, Steven Yi  wrote:
>>>>>>> I understand it's a workaround but, IMO, the build system has gotten
>>>>>>> worse as I now can not build at all because some value isn't set. It
>>>>>>> feels like the wrong solution.
>>>>>>> 
>>>>>>> On Sat, Apr 23, 2016 at 7:29 PM, Michael Gogins
>>>>>>>  wrote:
>>>>>>>> Yes. Set the value of STK_STATIC_LIBRARY on the CMake command line to
>>>>>>>> point to your system's static STK library.You should do the same for
>>>>>>>> PTHREAD_STATIC_LIBRARY.
>>>>>>>> 
>>>>>>>> This is due to a workaround for not obtaining a build of stkops.dll
>>>>>>>> that links statically to libstk.a. On my system, in spite of
>>>>>>>> instructions to the contrary, the value of STK_STATIC_LIBRARY is
>>>>>>>> reverted by CMake to -lstk no matter what I do... which then results
>>>>>>>> in linking to libstk.dll...  except for this fix, which brings the STK
>>>>>>>> static library into CMake as an "imported" library.
>>>>>>>> 
>>>>>>>> -----------------------------------------------------
>>>>>>>> Michael Gogins
>>>>>>>> Irreducible Productions
>>>>>>>> http://michaelgogins.tumblr.com
>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Sat, Apr 23, 2016 at 7:05 PM, Steven Yi  wrote:
>>>>>>>>> Hi All,
>>>>>>>>> 
>>>>>>>>> I just pulled the latest and I'm getting a CMake build problem now:
>>>>>>>>> 
>>>>>>>>> CMake Error at Opcodes/stk/CMakeLists.txt:25 (set_target_properties):
>>>>>>>>>  set_target_properties called with incorrect number of arguments.
>>>>>>>>> 
>>>>>>>>> I'm using Cmake 3.4.1.  Any ideas?
>>>>>>>>> 

I'd rather like to be able to use Visual Studio for development.  I
looked at it briefly and was able to get Cmake to generate a basic VS
project for libcsound and exes.  The issues are having a simple way to
get appropriate dependencies installed and setting up the search paths
so that those dependencies can be found. We would also need to spend
some times revising our flags for compiling/linking and they are
different for msvc.  I would expect the same amount of work or more to
get MS tools setup as I had spent for MSYS2.  However, I have not
followed VS-based development for years, so others might have a
simpler time of it.

MSYS2's use of pacman for dependencies simplifies a lot of things.  We
could potentially use nuget or choco to install dependencies, but I
can't say much as I have limited experience.

The goal originally was to get MSYS2 working, then MSVS.  MSYS2 seems
pretty close. The build I have now works with the exception of OSC and
STK opcodes.  I think this last bit of static linking is really the
last problem to solve.

On Mon, May 2, 2016 at 3:32 PM, Victor Lazzarini
 wrote:
> It all seems very confusing. How hard would be to build the whole thing with Microsoft tools?
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
>> On 2 May 2016, at 20:14, Steven Yi  wrote:
>>
>> Hi All,
>>
>> I did some further research and I think that something that might be
>> influencing the odd linking with winpthread-1.dll I'm seeing here is
>> that the GCC that gets installed via pacman on msys2 uses:
>>
>> Thread model: posix
>>
>> (found using 'gcc -v')
>>
>> Online, it seems like one should have a "Thread model: win32" version
>> of gcc to compile against -static-libgcc and ensure no
>> winpthreads-1.dll is pull in.
>>
>> Most of the text I saw referring to thread models of win32 and msys2
>> refer to gcc 4.9.x. I am guessing they changed to posix when going to
>> gcc 5.x.  I'm going to continue looking into this.
>>
>> steven
>>
>>
>>> On Fri, Apr 29, 2016 at 10:36 AM, Steven Yi  wrote:
>>> Just FYI, I continued to look into this but have not found a sensible
>>> cause yet.  I did also try installing clang and building with that.
>>> That seems to have a different set of problems with pthread linking.
>>> I will continue to look into this.
>>>
>>>> On Tue, Apr 26, 2016 at 11:22 AM, Steven Yi  wrote:
>>>> Finder scripts are great but it's not going to solve whether to add
>>>> $PTHREAD_LIBRARY or not.  We still need to verify threads exist but I
>>>> think we don't want to explicitly link to it on Windows if, as I
>>>> speculated, -static-libgcc brings that in automatically.
>>>>
>>>> What I'm seeing seems to support a different conclusion for the other
>>>> libraries. For example, I do see the use of -lstk instead of a full
>>>> path, but it is happening after a -Wl,-Bstatic flag.  So despite the
>>>> short lib name, I am still getting static links, as is shown with
>>>> dependency walker and ldd.  However, it is the two other libraries,
>>>> libwinpthread-1 and libstdc++6.dll, that are coming in somehow.
>>>> That's what I haven't understood yet.
>>>>
>>>> On Tue, Apr 26, 2016 at 11:13 AM, Michael Gogins
>>>>  wrote:
>>>>> The canonical approach is to write a FindXXX.cmake to encapsulate this logic
>>>>> and make it reusable by making it possible to call find_package. I suggest
>>>>> we write a FindPTHREAD.cmake. As a result of not doing this for many
>>>>> dependencies, our build system has become unnecessarily messy.
>>>>>
>>>>> However, doing this will still not solve the static linkage problem, which
>>>>> is caused by CMake not using the library pathname it has been given, not
>>>>> even if it is the full pathname, unless that pathname is a string literal
>>>>> passed to target_link_libraries, or my import library workaround is used.
>>>>>
>>>>> Best,
>>>>> Mike
>>>>>
>>>>> I spent some time looking into the static linking issue.  No solution
>>>>> so far, but one thing I found was that the CMake changes I had done in
>>>>> the main CmakeLists.txt that searched for the pthread library was
>>>>> privileging winpthread-1 over pthread.  That code for CMake was a bit
>>>>> clunky in retrospect (around like 457).  I replaced using:
>>>>>
>>>>> find_library(PTHREAD_LIBRARY NAMES pthread winpthread-1 pthreadGC2)
>>>>>
>>>>> which will pick up libpthread.a first (I believe the same one
>>>>> mentioned by Michael).  However, this causes linker problems when
>>>>> building libcsound (something about multiple definitions of pthread
>>>>> functions).  Anyways, I am going to continue looking at this to see if
>>>>> this is the more proper solution and, if so, how to fix up what is
>>>>> going on with the linker problems.
>>>>>
>>>>>> On Sun, Apr 24, 2016 at 6:18 PM, Steven Yi  wrote:
>>>>>> Sure, I understand this is a tricky problem and appreciate the time
>>>>>> spent on it. However, my problem was that the build went from building
>>>>>> what it could and not building what it couldn't, to not building at
>>>>>> all without intervention.  The latest changes you made restored being
>>>>>> to build here (well, I still have to manually turn off building Csound
>>>>>> AC because of music xml, which is hardcoded in the build.sh to a
>>>>>> location I do not have...). I'd ask that for any future changes, if
>>>>>> they do require some kind of manual intervention to enable building a
>>>>>> target, then they should gracefully disable building that target if
>>>>>> the manual intervention is not done so that the rest of the build
>>>>>> continues to function.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Apr 24, 2016 at 3:38 PM, Michael Gogins
>>>>>>  wrote:
>>>>>>> I spent several days on this, researched it thoroughly, found that
>>>>>>> other people had similar problems, and discovered this workaround,
>>>>>>> which is the only solution that appears to work in all cases. I am
>>>>>>> done with this for now. If you can find a better solution, I'll be
>>>>>>> happy to adopt it. In the meantime, I will update the build
>>>>>>> instructions and build.sh to reflect the workaround.
>>>>>>>
>>>>>>> Just to be clear, the goal here is for CMake and mingw64 to link all
>>>>>>> Csound plugins with only static library dependencies, in order to
>>>>>>> satisfy the requirements of Rory Walsh and other developers of Csound
>>>>>>> front ends.
>>>>>>>
>>>>>>> The problem is that even though the build.sh or build-mkg.sh scripts
>>>>>>> specify static versions of the pthread and stk libraries, when the
>>>>>>> makefile actually runs, CMake goes ahead and translates the
>>>>>>> user-specified pathnames from e.g.
>>>>>>> -DPTHREAD_LIBRARY:FILEPATH=/mingw64/x86_64-w64-mingw32/lib/libpthread.a
>>>>>>> (which is correct) to -lstk, and even with -Wl, -Bstatic -lstk, the
>>>>>>> dynamic version of the library seems to be what is used.
>>>>>>>
>>>>>>> I repeat, I fiddled with every way of doing this and only the
>>>>>>> workaround of importing the library from a CMake variable specifying
>>>>>>> the pathname for the static library works in all cases.
>>>>>>>
>>>>>>> In the meantime, I removed the STK_STATIC_LIBRARY and
>>>>>>> PTHREAD_STATIC_LIBRARY variables from the build files. The build
>>>>>>> should succeed without specifying the pathnames to static libraries,
>>>>>>> but if you don't, then these plugins will get dynamically linked.
>>>>>>>
>>>>>>> Best,
>>>>>>> Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----------------------------------------------------
>>>>>>> Michael Gogins
>>>>>>> Irreducible Productions
>>>>>>> http://michaelgogins.tumblr.com
>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>
>>>>>>>
>>>>>>>> On Sun, Apr 24, 2016 at 1:06 PM, Steven Yi  wrote:
>>>>>>>> I understand it's a workaround but, IMO, the build system has gotten
>>>>>>>> worse as I now can not build at all because some value isn't set. It
>>>>>>>> feels like the wrong solution.
>>>>>>>>
>>>>>>>> On Sat, Apr 23, 2016 at 7:29 PM, Michael Gogins
>>>>>>>>  wrote:
>>>>>>>>> Yes. Set the value of STK_STATIC_LIBRARY on the CMake command line to
>>>>>>>>> point to your system's static STK library.You should do the same for
>>>>>>>>> PTHREAD_STATIC_LIBRARY.
>>>>>>>>>
>>>>>>>>> This is due to a workaround for not obtaining a build of stkops.dll
>>>>>>>>> that links statically to libstk.a. On my system, in spite of
>>>>>>>>> instructions to the contrary, the value of STK_STATIC_LIBRARY is
>>>>>>>>> reverted by CMake to -lstk no matter what I do... which then results
>>>>>>>>> in linking to libstk.dll...  except for this fix, which brings the STK
>>>>>>>>> static library into CMake as an "imported" library.
>>>>>>>>>
>>>>>>>>> -----------------------------------------------------
>>>>>>>>> Michael Gogins
>>>>>>>>> Irreducible Productions
>>>>>>>>> http://michaelgogins.tumblr.com
>>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Sat, Apr 23, 2016 at 7:05 PM, Steven Yi  wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> I just pulled the latest and I'm getting a CMake build problem now:
>>>>>>>>>>
>>>>>>>>>> CMake Error at Opcodes/stk/CMakeLists.txt:25 (set_target_properties):
>>>>>>>>>>  set_target_properties called with incorrect number of arguments.
>>>>>>>>>>
>>>>>>>>>> I'm using Cmake 3.4.1.  Any ideas?
>>>>>>>>>>

Just my 2c.
I really appreciate the MSYS2 build, For many reasons. Among those the
simplicity of the build (at least the minimal one), which I think is
important in enabling more users to test new versions between
releases. Also the binary produced was *very* CPU effective as
compared with earlier (32 bit) versions. And MSYS being free and
open....

And in case it got lost in the din, as things were in early March,
osc.dll did build without these issues.


2016-05-02 21:48 GMT+02:00 Steven Yi :
> I'd rather like to be able to use Visual Studio for development.  I
> looked at it briefly and was able to get Cmake to generate a basic VS
> project for libcsound and exes.  The issues are having a simple way to
> get appropriate dependencies installed and setting up the search paths
> so that those dependencies can be found. We would also need to spend
> some times revising our flags for compiling/linking and they are
> different for msvc.  I would expect the same amount of work or more to
> get MS tools setup as I had spent for MSYS2.  However, I have not
> followed VS-based development for years, so others might have a
> simpler time of it.
>
> MSYS2's use of pacman for dependencies simplifies a lot of things.  We
> could potentially use nuget or choco to install dependencies, but I
> can't say much as I have limited experience.
>
> The goal originally was to get MSYS2 working, then MSVS.  MSYS2 seems
> pretty close. The build I have now works with the exception of OSC and
> STK opcodes.  I think this last bit of static linking is really the
> last problem to solve.
>
> On Mon, May 2, 2016 at 3:32 PM, Victor Lazzarini
>  wrote:
>> It all seems very confusing. How hard would be to build the whole thing with Microsoft tools?
>>
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>
>>> On 2 May 2016, at 20:14, Steven Yi  wrote:
>>>
>>> Hi All,
>>>
>>> I did some further research and I think that something that might be
>>> influencing the odd linking with winpthread-1.dll I'm seeing here is
>>> that the GCC that gets installed via pacman on msys2 uses:
>>>
>>> Thread model: posix
>>>
>>> (found using 'gcc -v')
>>>
>>> Online, it seems like one should have a "Thread model: win32" version
>>> of gcc to compile against -static-libgcc and ensure no
>>> winpthreads-1.dll is pull in.
>>>
>>> Most of the text I saw referring to thread models of win32 and msys2
>>> refer to gcc 4.9.x. I am guessing they changed to posix when going to
>>> gcc 5.x.  I'm going to continue looking into this.
>>>
>>> steven
>>>
>>>
>>>> On Fri, Apr 29, 2016 at 10:36 AM, Steven Yi  wrote:
>>>> Just FYI, I continued to look into this but have not found a sensible
>>>> cause yet.  I did also try installing clang and building with that.
>>>> That seems to have a different set of problems with pthread linking.
>>>> I will continue to look into this.
>>>>
>>>>> On Tue, Apr 26, 2016 at 11:22 AM, Steven Yi  wrote:
>>>>> Finder scripts are great but it's not going to solve whether to add
>>>>> $PTHREAD_LIBRARY or not.  We still need to verify threads exist but I
>>>>> think we don't want to explicitly link to it on Windows if, as I
>>>>> speculated, -static-libgcc brings that in automatically.
>>>>>
>>>>> What I'm seeing seems to support a different conclusion for the other
>>>>> libraries. For example, I do see the use of -lstk instead of a full
>>>>> path, but it is happening after a -Wl,-Bstatic flag.  So despite the
>>>>> short lib name, I am still getting static links, as is shown with
>>>>> dependency walker and ldd.  However, it is the two other libraries,
>>>>> libwinpthread-1 and libstdc++6.dll, that are coming in somehow.
>>>>> That's what I haven't understood yet.
>>>>>
>>>>> On Tue, Apr 26, 2016 at 11:13 AM, Michael Gogins
>>>>>  wrote:
>>>>>> The canonical approach is to write a FindXXX.cmake to encapsulate this logic
>>>>>> and make it reusable by making it possible to call find_package. I suggest
>>>>>> we write a FindPTHREAD.cmake. As a result of not doing this for many
>>>>>> dependencies, our build system has become unnecessarily messy.
>>>>>>
>>>>>> However, doing this will still not solve the static linkage problem, which
>>>>>> is caused by CMake not using the library pathname it has been given, not
>>>>>> even if it is the full pathname, unless that pathname is a string literal
>>>>>> passed to target_link_libraries, or my import library workaround is used.
>>>>>>
>>>>>> Best,
>>>>>> Mike
>>>>>>
>>>>>> I spent some time looking into the static linking issue.  No solution
>>>>>> so far, but one thing I found was that the CMake changes I had done in
>>>>>> the main CmakeLists.txt that searched for the pthread library was
>>>>>> privileging winpthread-1 over pthread.  That code for CMake was a bit
>>>>>> clunky in retrospect (around like 457).  I replaced using:
>>>>>>
>>>>>> find_library(PTHREAD_LIBRARY NAMES pthread winpthread-1 pthreadGC2)
>>>>>>
>>>>>> which will pick up libpthread.a first (I believe the same one
>>>>>> mentioned by Michael).  However, this causes linker problems when
>>>>>> building libcsound (something about multiple definitions of pthread
>>>>>> functions).  Anyways, I am going to continue looking at this to see if
>>>>>> this is the more proper solution and, if so, how to fix up what is
>>>>>> going on with the linker problems.
>>>>>>
>>>>>>> On Sun, Apr 24, 2016 at 6:18 PM, Steven Yi  wrote:
>>>>>>> Sure, I understand this is a tricky problem and appreciate the time
>>>>>>> spent on it. However, my problem was that the build went from building
>>>>>>> what it could and not building what it couldn't, to not building at
>>>>>>> all without intervention.  The latest changes you made restored being
>>>>>>> to build here (well, I still have to manually turn off building Csound
>>>>>>> AC because of music xml, which is hardcoded in the build.sh to a
>>>>>>> location I do not have...). I'd ask that for any future changes, if
>>>>>>> they do require some kind of manual intervention to enable building a
>>>>>>> target, then they should gracefully disable building that target if
>>>>>>> the manual intervention is not done so that the rest of the build
>>>>>>> continues to function.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Apr 24, 2016 at 3:38 PM, Michael Gogins
>>>>>>>  wrote:
>>>>>>>> I spent several days on this, researched it thoroughly, found that
>>>>>>>> other people had similar problems, and discovered this workaround,
>>>>>>>> which is the only solution that appears to work in all cases. I am
>>>>>>>> done with this for now. If you can find a better solution, I'll be
>>>>>>>> happy to adopt it. In the meantime, I will update the build
>>>>>>>> instructions and build.sh to reflect the workaround.
>>>>>>>>
>>>>>>>> Just to be clear, the goal here is for CMake and mingw64 to link all
>>>>>>>> Csound plugins with only static library dependencies, in order to
>>>>>>>> satisfy the requirements of Rory Walsh and other developers of Csound
>>>>>>>> front ends.
>>>>>>>>
>>>>>>>> The problem is that even though the build.sh or build-mkg.sh scripts
>>>>>>>> specify static versions of the pthread and stk libraries, when the
>>>>>>>> makefile actually runs, CMake goes ahead and translates the
>>>>>>>> user-specified pathnames from e.g.
>>>>>>>> -DPTHREAD_LIBRARY:FILEPATH=/mingw64/x86_64-w64-mingw32/lib/libpthread.a
>>>>>>>> (which is correct) to -lstk, and even with -Wl, -Bstatic -lstk, the
>>>>>>>> dynamic version of the library seems to be what is used.
>>>>>>>>
>>>>>>>> I repeat, I fiddled with every way of doing this and only the
>>>>>>>> workaround of importing the library from a CMake variable specifying
>>>>>>>> the pathname for the static library works in all cases.
>>>>>>>>
>>>>>>>> In the meantime, I removed the STK_STATIC_LIBRARY and
>>>>>>>> PTHREAD_STATIC_LIBRARY variables from the build files. The build
>>>>>>>> should succeed without specifying the pathnames to static libraries,
>>>>>>>> but if you don't, then these plugins will get dynamically linked.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Mike
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -----------------------------------------------------
>>>>>>>> Michael Gogins
>>>>>>>> Irreducible Productions
>>>>>>>> http://michaelgogins.tumblr.com
>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Sun, Apr 24, 2016 at 1:06 PM, Steven Yi  wrote:
>>>>>>>>> I understand it's a workaround but, IMO, the build system has gotten
>>>>>>>>> worse as I now can not build at all because some value isn't set. It
>>>>>>>>> feels like the wrong solution.
>>>>>>>>>
>>>>>>>>> On Sat, Apr 23, 2016 at 7:29 PM, Michael Gogins
>>>>>>>>>  wrote:
>>>>>>>>>> Yes. Set the value of STK_STATIC_LIBRARY on the CMake command line to
>>>>>>>>>> point to your system's static STK library.You should do the same for
>>>>>>>>>> PTHREAD_STATIC_LIBRARY.
>>>>>>>>>>
>>>>>>>>>> This is due to a workaround for not obtaining a build of stkops.dll
>>>>>>>>>> that links statically to libstk.a. On my system, in spite of
>>>>>>>>>> instructions to the contrary, the value of STK_STATIC_LIBRARY is
>>>>>>>>>> reverted by CMake to -lstk no matter what I do... which then results
>>>>>>>>>> in linking to libstk.dll...  except for this fix, which brings the STK
>>>>>>>>>> static library into CMake as an "imported" library.
>>>>>>>>>>
>>>>>>>>>> -----------------------------------------------------
>>>>>>>>>> Michael Gogins
>>>>>>>>>> Irreducible Productions
>>>>>>>>>> http://michaelgogins.tumblr.com
>>>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Sat, Apr 23, 2016 at 7:05 PM, Steven Yi  wrote:
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> I just pulled the latest and I'm getting a CMake build problem now:
>>>>>>>>>>>
>>>>>>>>>>> CMake Error at Opcodes/stk/CMakeLists.txt:25 (set_target_properties):
>>>>>>>>>>>  set_target_properties called with incorrect number of arguments.
>>>>>>>>>>>
>>>>>>>>>>> I'm using Cmake 3.4.1.  Any ideas?
>>>>>>>>>>>
>>>>>>>>>>> steven



-- 

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://flyndresang.no/

I can really see both sides of this.

On the one hand, thanks to a lot of work by you, by me, and by some
other people, the current MSYS2/mingw64 build system is far better
than the old mingw32 build system. I see no reason to fix what is not
really broken. I have identified issues and workarounds to ensure
static linkage for all Csound opcode DLLs and modules. I will get the
rtpa.dll module fixed the same way soon.

Furthermore, I am quite familiar with the stunning amount of work
required to really get a complete build of something like Csound
ported to a different operating system and/or toolchain. In my
professional experience and in my experience with Csound, and I have
done this for 4 different projects the size of Csound or bigger, it
takes anywhere from a few months to about a year of full-time work for
an experienced developer to get this right if it is done by hand.
Getting CMake to do it SHOULD take less time, but who knows?

On the other, there would be significant advantages, not least being
the ability to link directly between C++ libraries, Csound, and
toolkits such as the Chromium Embedded Framework and the Qt SDK. It
would be somewhat easier to create new projects or to compose directly
in C++ if Csound were built with the Microsoft toolchain.

I feel that the MSYS2/mingw64 toolchain and the Microsoft toolchain
are roughly on a par with the quality of the compiled code, both are
pretty good, so I don't think this is an issue.

I do think that the pacman system in MSYS2/mingw64 is a significant
advantage. I wonder if there is anything like this now that actually
works in the MIcrosoft world?

I would urge you to think very, very carefully about whether you
really want to commit to such a project. I have no particular motive
to do it myself, although if you got started, I would try to help as
time permits.

Best,

Thanks Michael for your comments.  I don't look forward to working on
another platform port, but at the same time, I'm not interested to do
big work on Csound's codebase without using an IDE like VS.  (XCode
worked well for me when I was on OSX.)   So there's a real value to
look into it personally.  Chocolatey Nuget does have a few of the
dependencies we need, so that should help.

Getting back to the MSYS2 stuff, I'm still confused on how you're able
to build OSC and STK without having the dynamic links creep in for
winpthread and libstdc++6?  I'm essentially linking with the same
libpthread.a that you are using.  Could you double check those opcode
libraries with dependency walker?  Also, could you tell me if your gcc
has posix or win32 thread model?  (gcc -v should tell)

Thanks!
steven


On Mon, May 2, 2016 at 5:19 PM, Michael Gogins  wrote:
> I can really see both sides of this.
>
> On the one hand, thanks to a lot of work by you, by me, and by some
> other people, the current MSYS2/mingw64 build system is far better
> than the old mingw32 build system. I see no reason to fix what is not
> really broken. I have identified issues and workarounds to ensure
> static linkage for all Csound opcode DLLs and modules. I will get the
> rtpa.dll module fixed the same way soon.
>
> Furthermore, I am quite familiar with the stunning amount of work
> required to really get a complete build of something like Csound
> ported to a different operating system and/or toolchain. In my
> professional experience and in my experience with Csound, and I have
> done this for 4 different projects the size of Csound or bigger, it
> takes anywhere from a few months to about a year of full-time work for
> an experienced developer to get this right if it is done by hand.
> Getting CMake to do it SHOULD take less time, but who knows?
>
> On the other, there would be significant advantages, not least being
> the ability to link directly between C++ libraries, Csound, and
> toolkits such as the Chromium Embedded Framework and the Qt SDK. It
> would be somewhat easier to create new projects or to compose directly
> in C++ if Csound were built with the Microsoft toolchain.
>
> I feel that the MSYS2/mingw64 toolchain and the Microsoft toolchain
> are roughly on a par with the quality of the compiled code, both are
> pretty good, so I don't think this is an issue.
>
> I do think that the pacman system in MSYS2/mingw64 is a significant
> advantage. I wonder if there is anything like this now that actually
> works in the MIcrosoft world?
>
> I would urge you to think very, very carefully about whether you
> really want to commit to such a project. I have no particular motive
> to do it myself, although if you got started, I would try to help as
> time permits.
>
> Best,

My compiler uses posix threads but of course the Win32 API threads can
be used explicitly:

$ gcc -v
Using built-in specs.
COLLECT_GCC=D:\msys64\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-5.3.0/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib
--with-gxx-include-dir=/mingw64/include/c++/5.3.0 --enable-bootstrap
--with-arch=x86-64 --with-tune=generic
--enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared
--enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-time=yes --disable-libstdcxx-pch
--disable-libstdcxx-debug --enable-version-specific-runtime-libs
--disable-isl-version-check --enable-lto --enable-libgomp
--disable-multilib --enable-checking=release --disable-rpath
--disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-libiconv --with-system-zlib
--with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64
--with-isl=/mingw64 --with-pkgversion='Rev5, Built by MSYS2 project'
--with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
--with-gnu-ld
Thread model: posix
gcc version 5.3.0 (Rev5, Built by MSYS2 project)

The problem with static linkage is that, as far as I can tell by
research and experience, CMake in the MSYS2/mingw64 toolchain simply
ignores what you say if some version of the library exists in
"standard locations." In other words, one may specify PTHREAD_LIBRARY
to CMake as I do:
-DPTHREAD_LIBRARY:FILEPATH=/mingw64/x86_64-w64-mingw32/lib/libpthread.a,
but then on the link line, one sees simply -lpthread. Apparently CMake
automatically stripes the filepath of everything but the lib name, if
that lib exists in any form in a "standard location" such as /usr/lib
or /lib.

At that point, gcc's linker rules take over: in order of decreasing
preference, link with libXXX.dll.a, libXXX.dll, or libXXX.a. SInce we
have .dll.a. and .dll for all of these, that is what gets linked,
ending up with a dependency on the DLL.

The workaround I found by googling stack overflow is to "import" the
respective library as static only, as in the example for rtpa below.
This is achieved starting with the add_library(pthread3 STATIC
IMPORTED) call. Then CMake will expand pthread3 in the
target_link_libraries call to the full pathname from
${PTHREAD_LIBRARY}. Go figure.

    if(BUILD_STATIC_LIBRARY)
        if(WIN32)
            set_source_files_properties(rtpa.c PROPERTIES LANGUAGE CXX)
            add_library(pthread3 STATIC IMPORTED)
            set_target_properties(pthread3 PROPERTIES
IMPORTED_LOCATION ${PTHREAD_LIBRARY})
            target_link_libraries(rtpa portaudio pthread3 winmm dsound
setupapi ${CSOUND_WINDOWS_LIBRARIES})
        else()
            target_link_libraries(rtpa portaudio ${PTHREAD_LIBRARY}
winmm dsound setupapi ${CSOUND_WINDOWS_LIBRARIES})
        endif()
    else()
      target_link_libraries(rtpa ${PTHREAD_LIBRARY} portaudio)
    endif()

Best,
Mike


-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Tue, May 3, 2016 at 1:51 PM, Steven Yi  wrote:
> Thanks Michael for your comments.  I don't look forward to working on
> another platform port, but at the same time, I'm not interested to do
> big work on Csound's codebase without using an IDE like VS.  (XCode
> worked well for me when I was on OSX.)   So there's a real value to
> look into it personally.  Chocolatey Nuget does have a few of the
> dependencies we need, so that should help.
>
> Getting back to the MSYS2 stuff, I'm still confused on how you're able
> to build OSC and STK without having the dynamic links creep in for
> winpthread and libstdc++6?  I'm essentially linking with the same
> libpthread.a that you are using.  Could you double check those opcode
> libraries with dependency walker?  Also, could you tell me if your gcc
> has posix or win32 thread model?  (gcc -v should tell)
>
> Thanks!
> steven
>
>
> On Mon, May 2, 2016 at 5:19 PM, Michael Gogins  wrote:
>> I can really see both sides of this.
>>
>> On the one hand, thanks to a lot of work by you, by me, and by some
>> other people, the current MSYS2/mingw64 build system is far better
>> than the old mingw32 build system. I see no reason to fix what is not
>> really broken. I have identified issues and workarounds to ensure
>> static linkage for all Csound opcode DLLs and modules. I will get the
>> rtpa.dll module fixed the same way soon.
>>
>> Furthermore, I am quite familiar with the stunning amount of work
>> required to really get a complete build of something like Csound
>> ported to a different operating system and/or toolchain. In my
>> professional experience and in my experience with Csound, and I have
>> done this for 4 different projects the size of Csound or bigger, it
>> takes anywhere from a few months to about a year of full-time work for
>> an experienced developer to get this right if it is done by hand.
>> Getting CMake to do it SHOULD take less time, but who knows?
>>
>> On the other, there would be significant advantages, not least being
>> the ability to link directly between C++ libraries, Csound, and
>> toolkits such as the Chromium Embedded Framework and the Qt SDK. It
>> would be somewhat easier to create new projects or to compose directly
>> in C++ if Csound were built with the Microsoft toolchain.
>>
>> I feel that the MSYS2/mingw64 toolchain and the Microsoft toolchain
>> are roughly on a par with the quality of the compiled code, both are
>> pretty good, so I don't think this is an issue.
>>
>> I do think that the pacman system in MSYS2/mingw64 is a significant
>> advantage. I wonder if there is anything like this now that actually
>> works in the MIcrosoft world?
>>
>> I would urge you to think very, very carefully about whether you
>> really want to commit to such a project. I have no particular motive
>> to do it myself, although if you got started, I would try to help as
>> time permits.
>>
>> Best,

P.S.: depends.exe shows NO dynamic library dependencies for rtpa.dll
except for Windows system libraries.

MKG

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Tue, May 3, 2016 at 2:07 PM, Michael Gogins  wrote:
> My compiler uses posix threads but of course the Win32 API threads can
> be used explicitly:
>
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=D:\msys64\mingw64\bin\gcc.exe
> COLLECT_LTO_WRAPPER=D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.3.0/lto-wrapper.exe
> Target: x86_64-w64-mingw32
> Configured with: ../gcc-5.3.0/configure --prefix=/mingw64
> --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
> --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
> --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
> --libexecdir=/mingw64/lib
> --with-gxx-include-dir=/mingw64/include/c++/5.3.0 --enable-bootstrap
> --with-arch=x86-64 --with-tune=generic
> --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared
> --enable-static --enable-libatomic --enable-threads=posix
> --enable-graphite --enable-fully-dynamic-string
> --enable-libstdcxx-time=yes --disable-libstdcxx-pch
> --disable-libstdcxx-debug --enable-version-specific-runtime-libs
> --disable-isl-version-check --enable-lto --enable-libgomp
> --disable-multilib --enable-checking=release --disable-rpath
> --disable-win32-registry --disable-nls --disable-werror
> --disable-symvers --with-libiconv --with-system-zlib
> --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64
> --with-isl=/mingw64 --with-pkgversion='Rev5, Built by MSYS2 project'
> --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
> --with-gnu-ld
> Thread model: posix
> gcc version 5.3.0 (Rev5, Built by MSYS2 project)
>
> The problem with static linkage is that, as far as I can tell by
> research and experience, CMake in the MSYS2/mingw64 toolchain simply
> ignores what you say if some version of the library exists in
> "standard locations." In other words, one may specify PTHREAD_LIBRARY
> to CMake as I do:
> -DPTHREAD_LIBRARY:FILEPATH=/mingw64/x86_64-w64-mingw32/lib/libpthread.a,
> but then on the link line, one sees simply -lpthread. Apparently CMake
> automatically stripes the filepath of everything but the lib name, if
> that lib exists in any form in a "standard location" such as /usr/lib
> or /lib.
>
> At that point, gcc's linker rules take over: in order of decreasing
> preference, link with libXXX.dll.a, libXXX.dll, or libXXX.a. SInce we
> have .dll.a. and .dll for all of these, that is what gets linked,
> ending up with a dependency on the DLL.
>
> The workaround I found by googling stack overflow is to "import" the
> respective library as static only, as in the example for rtpa below.
> This is achieved starting with the add_library(pthread3 STATIC
> IMPORTED) call. Then CMake will expand pthread3 in the
> target_link_libraries call to the full pathname from
> ${PTHREAD_LIBRARY}. Go figure.
>
>     if(BUILD_STATIC_LIBRARY)
>         if(WIN32)
>             set_source_files_properties(rtpa.c PROPERTIES LANGUAGE CXX)
>             add_library(pthread3 STATIC IMPORTED)
>             set_target_properties(pthread3 PROPERTIES
> IMPORTED_LOCATION ${PTHREAD_LIBRARY})
>             target_link_libraries(rtpa portaudio pthread3 winmm dsound
> setupapi ${CSOUND_WINDOWS_LIBRARIES})
>         else()
>             target_link_libraries(rtpa portaudio ${PTHREAD_LIBRARY}
> winmm dsound setupapi ${CSOUND_WINDOWS_LIBRARIES})
>         endif()
>     else()
>       target_link_libraries(rtpa ${PTHREAD_LIBRARY} portaudio)
>     endif()
>
> Best,
> Mike
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Tue, May 3, 2016 at 1:51 PM, Steven Yi  wrote:
>> Thanks Michael for your comments.  I don't look forward to working on
>> another platform port, but at the same time, I'm not interested to do
>> big work on Csound's codebase without using an IDE like VS.  (XCode
>> worked well for me when I was on OSX.)   So there's a real value to
>> look into it personally.  Chocolatey Nuget does have a few of the
>> dependencies we need, so that should help.
>>
>> Getting back to the MSYS2 stuff, I'm still confused on how you're able
>> to build OSC and STK without having the dynamic links creep in for
>> winpthread and libstdc++6?  I'm essentially linking with the same
>> libpthread.a that you are using.  Could you double check those opcode
>> libraries with dependency walker?  Also, could you tell me if your gcc
>> has posix or win32 thread model?  (gcc -v should tell)
>>
>> Thanks!
>> steven
>>
>>
>> On Mon, May 2, 2016 at 5:19 PM, Michael Gogins  wrote:
>>> I can really see both sides of this.
>>>
>>> On the one hand, thanks to a lot of work by you, by me, and by some
>>> other people, the current MSYS2/mingw64 build system is far better
>>> than the old mingw32 build system. I see no reason to fix what is not
>>> really broken. I have identified issues and workarounds to ensure
>>> static linkage for all Csound opcode DLLs and modules. I will get the
>>> rtpa.dll module fixed the same way soon.
>>>
>>> Furthermore, I am quite familiar with the stunning amount of work
>>> required to really get a complete build of something like Csound
>>> ported to a different operating system and/or toolchain. In my
>>> professional experience and in my experience with Csound, and I have
>>> done this for 4 different projects the size of Csound or bigger, it
>>> takes anywhere from a few months to about a year of full-time work for
>>> an experienced developer to get this right if it is done by hand.
>>> Getting CMake to do it SHOULD take less time, but who knows?
>>>
>>> On the other, there would be significant advantages, not least being
>>> the ability to link directly between C++ libraries, Csound, and
>>> toolkits such as the Chromium Embedded Framework and the Qt SDK. It
>>> would be somewhat easier to create new projects or to compose directly
>>> in C++ if Csound were built with the Microsoft toolchain.
>>>
>>> I feel that the MSYS2/mingw64 toolchain and the Microsoft toolchain
>>> are roughly on a par with the quality of the compiled code, both are
>>> pretty good, so I don't think this is an issue.
>>>
>>> I do think that the pacman system in MSYS2/mingw64 is a significant
>>> advantage. I wonder if there is anything like this now that actually
>>> works in the MIcrosoft world?
>>>
>>> I would urge you to think very, very carefully about whether you
>>> really want to commit to such a project. I have no particular motive
>>> to do it myself, although if you got started, I would try to help as
>>> time permits.
>>>
>>> Best,

Well, I have no dynamic libs for rtpa.dll either.  Could you check OSC
and stkops? My issues are only with those opcode libs at this point.
osc.dll shows a link to libwinpthread-1 and stkops shows a link to
libstdc++6.  I am using the build settings I have here which are not
going through the special conditions you put in.  With this, the issue
is: everything else links statically properly, why not these two
specific libraries?

Also, as mentioned, when modifying the pthread search to favor pthread
over winpthread, I have to explicitly *not* add pthread as
static-libgcc looks to add that already. (If I do add it, the build
fails with multiple symbols defined for pthread-related functions.)
With that, the link command that gets used for osc and stkops are:

[OSC]

cd /C/msys64/home/stevenyi/work/csound/csound/mingw64/csound-mingw64/Opcodes
&& /C/msys64/mingw64/bin/gcc.exe    -mfpmath=sse -msse2
-fomit-frame-pointer -mstackrealign -static-libgcc -static
-fvisibility=hidden -O2 -g -DNDEBUG  -Wl,--add-stdcall-alias -shared
-o ../osc.dll -Wl,--major-image-version,0,--minor-image-version,0
-Wl,--whole-archive CMakeFiles/osc.dir/objects.a
-Wl,--no-whole-archive -Wl,-Bstatic -llo -Wl,-Bdynamic -lwsock32
-lws2_32 -liphlpapi -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32
-lole3 2 -loleaut32 -luuid -lcomdlg32 -ladvapi32

[STK]

cd /C/msys64/home/stevenyi/work/csound/csound/mingw64/csound-mingw64/Opcodes/stk
&& /C/msys64/mingw64/bin/g++.exe    -mfpmath=sse -msse2
-fomit-frame-pointer -mstackrealign -static-libstdc++ -static-libgcc
-static -fvisibility=hidden -O2 -g -DNDEBUG  -Wl,--add-stdcall-alias
-shared -o ../../stkops.dll
-Wl,--major-image-version,0,--minor-image-version,0
-Wl,--whole-archive CMakeFiles/stkops.dir/objects.a
-Wl,--no-whole-archive -Wl,-Bstatic -lstk -Wl,-Bdynamic -lkernel32
-luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid
-lcomdlg32 -ladvapi32

On Tue, May 3, 2016 at 2:10 PM, Michael Gogins  wrote:
> P.S.: depends.exe shows NO dynamic library dependencies for rtpa.dll
> except for Windows system libraries.
>
> MKG
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Tue, May 3, 2016 at 2:07 PM, Michael Gogins  wrote:
>> My compiler uses posix threads but of course the Win32 API threads can
>> be used explicitly:
>>
>> $ gcc -v
>> Using built-in specs.
>> COLLECT_GCC=D:\msys64\mingw64\bin\gcc.exe
>> COLLECT_LTO_WRAPPER=D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.3.0/lto-wrapper.exe
>> Target: x86_64-w64-mingw32
>> Configured with: ../gcc-5.3.0/configure --prefix=/mingw64
>> --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
>> --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
>> --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
>> --libexecdir=/mingw64/lib
>> --with-gxx-include-dir=/mingw64/include/c++/5.3.0 --enable-bootstrap
>> --with-arch=x86-64 --with-tune=generic
>> --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared
>> --enable-static --enable-libatomic --enable-threads=posix
>> --enable-graphite --enable-fully-dynamic-string
>> --enable-libstdcxx-time=yes --disable-libstdcxx-pch
>> --disable-libstdcxx-debug --enable-version-specific-runtime-libs
>> --disable-isl-version-check --enable-lto --enable-libgomp
>> --disable-multilib --enable-checking=release --disable-rpath
>> --disable-win32-registry --disable-nls --disable-werror
>> --disable-symvers --with-libiconv --with-system-zlib
>> --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64
>> --with-isl=/mingw64 --with-pkgversion='Rev5, Built by MSYS2 project'
>> --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
>> --with-gnu-ld
>> Thread model: posix
>> gcc version 5.3.0 (Rev5, Built by MSYS2 project)
>>
>> The problem with static linkage is that, as far as I can tell by
>> research and experience, CMake in the MSYS2/mingw64 toolchain simply
>> ignores what you say if some version of the library exists in
>> "standard locations." In other words, one may specify PTHREAD_LIBRARY
>> to CMake as I do:
>> -DPTHREAD_LIBRARY:FILEPATH=/mingw64/x86_64-w64-mingw32/lib/libpthread.a,
>> but then on the link line, one sees simply -lpthread. Apparently CMake
>> automatically stripes the filepath of everything but the lib name, if
>> that lib exists in any form in a "standard location" such as /usr/lib
>> or /lib.
>>
>> At that point, gcc's linker rules take over: in order of decreasing
>> preference, link with libXXX.dll.a, libXXX.dll, or libXXX.a. SInce we
>> have .dll.a. and .dll for all of these, that is what gets linked,
>> ending up with a dependency on the DLL.
>>
>> The workaround I found by googling stack overflow is to "import" the
>> respective library as static only, as in the example for rtpa below.
>> This is achieved starting with the add_library(pthread3 STATIC
>> IMPORTED) call. Then CMake will expand pthread3 in the
>> target_link_libraries call to the full pathname from
>> ${PTHREAD_LIBRARY}. Go figure.
>>
>>     if(BUILD_STATIC_LIBRARY)
>>         if(WIN32)
>>             set_source_files_properties(rtpa.c PROPERTIES LANGUAGE CXX)
>>             add_library(pthread3 STATIC IMPORTED)
>>             set_target_properties(pthread3 PROPERTIES
>> IMPORTED_LOCATION ${PTHREAD_LIBRARY})
>>             target_link_libraries(rtpa portaudio pthread3 winmm dsound
>> setupapi ${CSOUND_WINDOWS_LIBRARIES})
>>         else()
>>             target_link_libraries(rtpa portaudio ${PTHREAD_LIBRARY}
>> winmm dsound setupapi ${CSOUND_WINDOWS_LIBRARIES})
>>         endif()
>>     else()
>>       target_link_libraries(rtpa ${PTHREAD_LIBRARY} portaudio)
>>     endif()
>>
>> Best,
>> Mike
>>
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Tue, May 3, 2016 at 1:51 PM, Steven Yi  wrote:
>>> Thanks Michael for your comments.  I don't look forward to working on
>>> another platform port, but at the same time, I'm not interested to do
>>> big work on Csound's codebase without using an IDE like VS.  (XCode
>>> worked well for me when I was on OSX.)   So there's a real value to
>>> look into it personally.  Chocolatey Nuget does have a few of the
>>> dependencies we need, so that should help.
>>>
>>> Getting back to the MSYS2 stuff, I'm still confused on how you're able
>>> to build OSC and STK without having the dynamic links creep in for
>>> winpthread and libstdc++6?  I'm essentially linking with the same
>>> libpthread.a that you are using.  Could you double check those opcode
>>> libraries with dependency walker?  Also, could you tell me if your gcc
>>> has posix or win32 thread model?  (gcc -v should tell)
>>>
>>> Thanks!
>>> steven
>>>
>>>
>>> On Mon, May 2, 2016 at 5:19 PM, Michael Gogins  wrote:
>>>> I can really see both sides of this.
>>>>
>>>> On the one hand, thanks to a lot of work by you, by me, and by some
>>>> other people, the current MSYS2/mingw64 build system is far better
>>>> than the old mingw32 build system. I see no reason to fix what is not
>>>> really broken. I have identified issues and workarounds to ensure
>>>> static linkage for all Csound opcode DLLs and modules. I will get the
>>>> rtpa.dll module fixed the same way soon.
>>>>
>>>> Furthermore, I am quite familiar with the stunning amount of work
>>>> required to really get a complete build of something like Csound
>>>> ported to a different operating system and/or toolchain. In my
>>>> professional experience and in my experience with Csound, and I have
>>>> done this for 4 different projects the size of Csound or bigger, it
>>>> takes anywhere from a few months to about a year of full-time work for
>>>> an experienced developer to get this right if it is done by hand.
>>>> Getting CMake to do it SHOULD take less time, but who knows?
>>>>
>>>> On the other, there would be significant advantages, not least being
>>>> the ability to link directly between C++ libraries, Csound, and
>>>> toolkits such as the Chromium Embedded Framework and the Qt SDK. It
>>>> would be somewhat easier to create new projects or to compose directly
>>>> in C++ if Csound were built with the Microsoft toolchain.
>>>>
>>>> I feel that the MSYS2/mingw64 toolchain and the Microsoft toolchain
>>>> are roughly on a par with the quality of the compiled code, both are
>>>> pretty good, so I don't think this is an issue.
>>>>
>>>> I do think that the pacman system in MSYS2/mingw64 is a significant
>>>> advantage. I wonder if there is anything like this now that actually
>>>> works in the MIcrosoft world?
>>>>
>>>> I would urge you to think very, very carefully about whether you
>>>> really want to commit to such a project. I have no particular motive
>>>> to do it myself, although if you got started, I would try to help as
>>>> time permits.
>>>>
>>>> Best,

I have no dynamic linkage at all except for some codecs used by libsndfile. My osc and stkops are clean.

I do not know why these two libraries. The answer might be in the details of the build (different CMake commands, different compiler options, different pragmas, different installation directories).

Best,
Mike

The discrepancy is odd as the support libs for libsndfile on my system are statically linked in (it was one of the first things I had to deal with for the msys2 build).

It is very odd, and years ago there were issues with libFLAC  in the x86 windows build, which we never understood. What happened then is that if something loaded Csound from outside the Csound directory, there would be a message box indicating an error, but one could continue through the error and Csound would then run normally.

Best,
Mike

It is very odd, and years ago there were issues with libFLAC  in the x86 windows build, which we never understood. What happened then is that if something loaded Csound from outside the Csound directory, there would be a message box indicating an error, but one c ould continue through the error and Csound would then run normally.

Best,
Mike

On May 3, 2016 5:34 PM, "Steven Yi" <stevenyi@gmail.com> wrote:

The discrepancy is odd as the support libs for libsndfile on my system are statically linked in (it was one of the first things I had to deal with for the msys2 build).

On Tue, May 3, 2016, 5:26 PM Michael Gogins <michael.gogins@gmail.com> wrote:

I have no dynamic linkage at all except for some codecs used by libsndfile. My osc and stkops are clean.

I do not know why these two libraries. The answer might be in the details of the build (different CMake commands, different compiler options, different pragmas, different installation directories).

Best,
Mike

On May 3, 2016 4:52 PM, "Steven Yi" <stevenyi@gmail.com> wrote:

Well, I have no dynamic libs for rtpa.dll either.  Could you check OSC
and stkops? My issues are only with those opcode libs at this point.
osc.dll shows a link to libwinpthread-1 and stkops shows a link to
libstdc++6.  I am using the build settings I have here which are not
going through the special conditions you put in.  With this, the issue
is: everything else links statically properly, why not these two
specific libraries?

Also, as mentioned, when modifying the pthread search to favor pthread
over winpthread, I have to explicitly *not* add pthread as
static-libgcc looks to add that already. (If I do add it, the build
fails with multiple symbols defined for pthread-related functions.)
With that, the link command that gets used for osc and stkops are:

[OSC]

cd /C/msys64/home/stevenyi/work/csound/csound/mingw64/csound-mingw64/Opcodes
&& /C/msys64/mingw64/bin/gcc.exe    -mfpmath=sse -msse2
-fomit-frame-pointer -mstackrealign -static-libgcc -static
-fvisibility=hidden -O2 -g -DNDEBUG  -Wl,--add-stdcall-alias -shared
-o ../osc.dll -Wl,--major-image-version,0,--minor-image-version,0
-Wl,--whole-archive CMakeFiles/osc.dir/objects.a
-Wl,--no-whole-archive -Wl,-Bstatic -llo -Wl,-Bdynamic -lwsock32
-lws2_32 -liphlpapi -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32
-lole3 2 -loleaut32 -luuid -lcomdlg32 -ladvapi32

[STK]

cd /C/msys64/home/stevenyi/work/csound/csound/mingw64/csound-mingw64/Opcodes/stk
&& /C/msys64/mingw64/bin/g++.exe    -mfpmath=sse -msse2
-fomit-frame-pointer -mstackrealign -static-libstdc++ -static-libgcc
-static -fvisibility=hidden -O2 -g -DNDEBUG  -Wl,--add-stdcall-alias
-shared -o ../../stkops.dll
-Wl,--major-image-version,0,--minor-image-version,0
-Wl,--whole-archive CMakeFiles/stkops.dir/objects.a
-Wl,--no-whole-archive -Wl,-Bstatic -lstk -Wl,-Bdynamic -lkernel32
-luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid
-lcomdlg32 -ladvapi32

On Tue, May 3, 2016 at 2:10 PM, Michael Gogins <michael.gogins@gmail.com> wrote:
> P.S.: depends.exe shows NO dynamic library dependencies for rtpa.dll
> except for Windows system libraries.
>
> MKG
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Tue, May 3, 2016 at 2:07 PM, Michael Gogins <michael.gogins@gmail.com> wrote:
>> My compiler uses posix threads but of course the Win32 API threads can
>> be used explicitly:
>>
>> $ gcc -v
>> Using built-in specs.
>> COLLECT_GCC=D:\msys64\mingw64\bin\gcc.exe
>> COLLECT_LTO_WRAPPER=D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.3.0/lto-wrapper.exe
>> Target: x86_64-w64-mingw32
>> Configured with: ../gcc-5.3.0/configure --prefix=/mingw64
>> --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
>> --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
>> --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
>> --libexecdir=/mingw64/lib
>> --with-gxx-include-dir=/mingw64/include/c++/5.3.0 --enable-bootstrap
>> --with-arch=x86-64 --with-tune=generic
>> --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared
>> --enable-static --enable-libatomic --enable-threads=posix
>> --enable-graphite --enable-fully-dynamic-string
>> --enable-libstdcxx-time=yes --disable-libstdcxx-pch
>> --disable-libstdcxx-debug --enable-version-specific-runtime-libs
>> --disable-isl-version-check --enable-lto --enable-libgomp
>> --disable-multilib --enable-checking=release --disable-rpath
>> --disable-win32-registry --disable-nls --disable-werror
>> --disable-symvers --with-libiconv --with-system-zlib
>> --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64
>> --with-isl=/mingw64 --with-pkgversion='Rev5, Built by MSYS2 project'
>> --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
>> --with-gnu-ld
>> Thread model: posix
>> gcc version 5.3.0 (Rev5, Built by MSYS2 project)
>>
>> The problem with static linkage is that, as far as I can tell by
>> research and experience, CMake in the MSYS2/mingw64 toolchain simply
>> ignores what you say if some version of the library exists in
>> "standard locations." In other words, one may specify PTHREAD_LIBRARY
>> to CMake as I do:
>> -DPTHREAD_LIBRARY:FILEPATH=/mingw64/x86_64-w64-mingw32/lib/libpthread.a,
>> but then on the link line, one sees simply -lpthread. Apparently CMake
>> automatically stripes the filepath of everything but the lib name, if
>> that lib exists in any form in a "standard location" such as /usr/lib
>> or /lib.
>>
>> At that point, gcc's linker rules take over: in order of decreasing
>> preference, link with libXXX.dll.a, libXXX.dll, or libXXX.a. SInce we
>> have .dll.a. and .dll for all of these, that is what gets linked,
>> ending up with a dependency on the DLL.
>>
>> The workaround I found by googling stack overflow is to "import" the
>> respective library as static only, as in the example for rtpa below.
>> This is achieved starting with the add_library(pthread3 STATIC
>> IMPORTED) call. Then CMake will expand pthread3 in the
>> target_link_libraries call to the full pathname from
>> ${PTHREAD_LIBRARY}. Go figure.
>>
>>     if(BUILD_STATIC_LIBRARY)
>>         if(WIN32)
>>             set_source_files_properties(rtpa.c PROPERTIES LANGUAGE CXX)
>>             add_library(pthread3 STATIC IMPORTED)
>>             set_target_properties(pthread3 PROPERTIES
>> IMPORTED_LOCATION ${PTHREAD_LIBRARY})
>>             target_link_libraries(rtpa portaudio pthread3 winmm dsound
>> setupapi ${CSOUND_WINDOWS_LIBRARIES})
>>         else()
>>             target_link_libraries(rtpa portaudio ${PTHREAD_LIBRARY}
>> winmm dsound setupapi ${CSOUND_WINDOWS_LIBRARIES})
>>         endif()
>>     else()
>>       target_link_libraries(rtpa ${PTHREAD_LIBRARY} portaudio)
>>     endif()
>>
>> Best,
>> Mike
>>
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Tue, May 3, 2016 at 1:51 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>> Thanks Michael for your comments.  I don't look forward to working on
>>> another platform port, but at the same time, I'm not interested to do
>>> big work on Csound's codebase without using an IDE like VS.  (XCode
>>> worked well for me when I was on OSX.)   So there's a real value to
>>> look into it personally.  Chocolatey Nuget does have a few of the
>>> dependencies we need, so that should help.
>>>
>>> Getting back to the MSYS2 stuff, I'm still confused on how you're able
>>> to build OSC and STK without having the dynamic links creep in for
>>> winpthread and libstdc++6?  I'm essentially linking with the same
>>> libpthread.a that you are using.  Could you double check those opcode
>>> libraries with dependency walker?  Also, could you tell me if your gcc
>>> has posix or win32 thread model?  (gcc -v should tell)
>>>
>>> Thanks!
>>> steven
>>>
>>>
>>> On Mon, May 2, 2016 at 5:19 PM, Michael Gogins <michael.gogins@gmail.com> wrote:
>>>> I can really see both sides of this.
>>>>
>>>> On the one hand, thanks to a lot of work by you, by me, and by some
>>>> other people, the current MSYS2/mingw64 build system is far better
>>>> than the old mingw32 build system. I see no reason to fix what is not
>>>> really broken. I have identified issues and workarounds to ensure
>>>> static linkage for all Csound opcode DLLs and modules. I will get the
>>>> rtpa.dll module fixed the same way soon.
>>>>
>>>> Furthermore, I am quite familiar with the stunning amount of work
>>>> required to really get a complete build of something like Csound
>>>> ported to a different operating system and/or toolchain. In my
>>>> professional experience and in my experience with Csound, and I have
>>>> done this for 4 different projects the size of Csound or bigger, it
>>>> takes anywhere from a few months to about a year of full-time work for
>>>> an experienced developer to get this right if it is done by hand.
>>>> Getting CMake to do it SHOULD take less time, but who knows?
>>>>
>>>> On the other, there would be significant advantages, not least being
>>>> the ability to link directly between C++ libraries, Csound, and
>>>> toolkits such as the Chromium Embedded Framework and the Qt SDK. It
>>>> would be somewhat easier to create new projects or to compose directly
>>>> in C++ if Csound were built with the Microsoft toolchain.
>>>>
>>>> I feel that the MSYS2/mingw64 toolchain and the Microsoft toolchain
>>>> are roughly on a par with the quality of the compiled code, both are
>>>> pretty good, so I don't think this is an issue.
>>>>
>>>> I do think that the pacman system in MSYS2/mingw64 is a significant
>>>> advantage. I wonder if there is anything like this now that actually
>>>> works in the MIcrosoft world?
>>>>
>>>> I would urge you to think very, very carefully about whether you
>>>> really want to commit to such a project. I have no particular motive
>>>> to do it myself, although if you got started, I would try to help as
>>>> time permits.
>>>>
>>>> Best,
>>>> Mike

I thin I fied it

On Wed, 4 May 2016, Victor Lazzarini wrote:

> Can you make sure the options you put for Windows are windows-only. It's
> breaking the build on travis
> 
> Victor LazzariniDean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland