LIblo requires pthreads. And that is in fact the source of this
dependency as far as I can tell. I think the build recipe for liblo
could be changed to use a static version of pthreads, however.

By the way, I am not sure the static build idea is required for
Csound. I was able to run CsoundVST about a year ago with Reaper in
spite of DLL conflicts by ensuring that all DLLs required by Csound
were in the VST bin directory.

There also now appears to be a new crash in CsoundQt realted to the
Csound MIDI module.

The other issue I am looking at is a problem with line endings in
CsoundQt. No matter what the number of line endings for each line
keeps increasing, and it's impossible to turn off the Windows line
endings. I think I should be able to fix this one though.

Best,
Mike





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


On Mon, Apr 18, 2016 at 6:53 PM, Steven Yi  wrote:
> Btw: we used to have separate thread implementations. We switched to
> pthreads, but perhaps this was a mistake and we should have kept the
> implementations but reduced it down to just pthreads, win32, and no-op. If
> liblo requires pthreads though, not much to do there about that.
>
>
> On Mon, Apr 18, 2016 at 6:46 PM Steven Yi  wrote:
>>
>> Have you looked at the Git history? I haven't been following that closely
>> but the last build I did from yesterday had a problem where the Virtual
>> keyboard didn't send any midi values. I suspect it has to do with recent
>> lock changes, but I am just guessing. Besides these issues, what else is
>> there?
>> On Mon, Apr 18, 2016 at 6:38 PM Rory Walsh  wrote:
>>>
>>> Oeyvind and I have been trying to figure out what happened to the Windows
>>> build in mid-march which resulted in osc.dll requiring the lib-pthread .dll
>>> to be present in order to run. It was wasn't like this before then, but we
>>> can't tell what happened to change it. Anyone have any ideas? I can't use
>>> the canonical release of Csound lib to build Cabbage because of all the .dll
>>> dependencies, but I would love if we could still try to ensure as much of

To summarise the line ending situation, if text support is designed to handle different kinds of line endings, it is best to load files in text mode, edit them with line feeds only, and save them in binary mode after replacing the line feeds with the appropriate line ending sequence for the operating system or as chosen by the user. Note that the Qt SDK text editing system works internally using line feeds only.

Regards,
Mike

I don't know the fine details about the technicalities of this, but I
can confirm that osc.dll was built and working in the Csound version I
built March 7th. I tested this again just now. Open Sound Control also
confirmed working in this version. To me, this seems like a strong
indicator that it is indeed possible to build osc.dll without getting
the libpthread dependency. This version does not complain about any
missing dlls, whereas the more recent ones show an error dialog at
startup (unless the dlls are distributed in the csound/bin folder).
I think it is *very* important we get this sorted out, as it will mean
the different frontends and other ways of acessing Csound will
otherwise interfere in unpredictable ways,


2016-04-19 2:27 GMT+02:00 Michael Gogins :
> LIblo requires pthreads. And that is in fact the source of this
> dependency as far as I can tell. I think the build recipe for liblo
> could be changed to use a static version of pthreads, however.
>
> By the way, I am not sure the static build idea is required for
> Csound. I was able to run CsoundVST about a year ago with Reaper in
> spite of DLL conflicts by ensuring that all DLLs required by Csound
> were in the VST bin directory.
>
> There also now appears to be a new crash in CsoundQt realted to the
> Csound MIDI module.
>
> The other issue I am looking at is a problem with line endings in
> CsoundQt. No matter what the number of line endings for each line
> keeps increasing, and it's impossible to turn off the Windows line
> endings. I think I should be able to fix this one though.
>
> Best,
> Mike
>
>
>
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Mon, Apr 18, 2016 at 6:53 PM, Steven Yi  wrote:
>> Btw: we used to have separate thread implementations. We switched to
>> pthreads, but perhaps this was a mistake and we should have kept the
>> implementations but reduced it down to just pthreads, win32, and no-op. If
>> liblo requires pthreads though, not much to do there about that.
>>
>>
>> On Mon, Apr 18, 2016 at 6:46 PM Steven Yi  wrote:
>>>
>>> Have you looked at the Git history? I haven't been following that closely
>>> but the last build I did from yesterday had a problem where the Virtual
>>> keyboard didn't send any midi values. I suspect it has to do with recent
>>> lock changes, but I am just guessing. Besides these issues, what else is
>>> there?
>>> On Mon, Apr 18, 2016 at 6:38 PM Rory Walsh  wrote:
>>>>
>>>> Oeyvind and I have been trying to figure out what happened to the Windows
>>>> build in mid-march which resulted in osc.dll requiring the lib-pthread .dll
>>>> to be present in order to run. It was wasn't like this before then, but we
>>>> can't tell what happened to change it. Anyone have any ideas? I can't use
>>>> the canonical release of Csound lib to build Cabbage because of all the .dll
>>>> dependencies, but I would love if we could still try to ensure as much of
>>>> the plugin opcodes build statically as possible.



-- 

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/

What are the results of running ldd on both versions of osc.dll?

Regards,
Mike

Here, the first one is my own build from March 7th, the second one is
the Gogins rc2

Administrator@HF-31335 MINGW64 /c/Program Files/Csound6_x64_mymars/plugins64
$ ldd osc.dll
        ntdll.dll => /c/windows/SYSTEM32/ntdll.dll (0x773c0000)
        kernel32.dll => /c/windows/system32/kernel32.dll (0x771a0000)
        KERNELBASE.dll => /c/windows/system32/KERNELBASE.dll (0x7fefd210000)
        fshook64.dll => /c/program files
(x86)/f-secure/hips/fshook64.dll (0x737
    d0000)
        PSAPI.DLL => /c/windows/system32/PSAPI.DLL (0x77590000)
        ADVAPI32.dll => /c/windows/system32/ADVAPI32.dll (0x7fefd6e0000)
        msvcrt.dll => /c/windows/system32/msvcrt.dll (0x7fefe0f0000)
        sechost.dll => /c/windows/SYSTEM32/sechost.dll (0x7fefdbd0000)
        RPCRT4.dll => /c/windows/system32/RPCRT4.dll (0x7fefdfc0000)
        IPHLPAPI.DLL => /c/windows/system32/IPHLPAPI.DLL (0x7fefa2c0000)
        NSI.dll => /c/windows/system32/NSI.dll (0x7fefd810000)
        WINNSI.DLL => /c/windows/system32/WINNSI.DLL (0x7fefa2a0000)
        USER32.dll => /c/windows/system32/USER32.dll (0x772c0000)
        GDI32.dll => /c/windows/system32/GDI32.dll (0x7fefe1e0000)
        LPK.dll => /c/windows/system32/LPK.dll (0x7fefe4e0000)
        USP10.dll => /c/windows/system32/USP10.dll (0x7fefe5d0000)
        WS2_32.dll => /c/windows/system32/WS2_32.dll (0x7fefd7c0000)
        WSOCK32.dll => /c/windows/system32/WSOCK32.dll (0x7fef00b0000)
        IMM32.DLL => /c/windows/system32/IMM32.DLL (0x7fefe1b0000)
        MSCTF.dll => /c/windows/system32/MSCTF.dll (0x7fefe830000)


Administrator@HF-31335 MINGW64 /c/Program Files/Csound6_x64/plugins64
$ ldd osc.dll
        ntdll.dll => /c/windows/SYSTEM32/ntdll.dll (0x773c0000)
        kernel32.dll => /c/windows/system32/kernel32.dll (0x771a0000)
        KERNELBASE.dll => /c/windows/system32/KERNELBASE.dll (0x7fefd210000)
        fshook64.dll => /c/program files
(x86)/f-secure/hips/fshook64.dll (0x737d0000)
        PSAPI.DLL => /c/windows/system32/PSAPI.DLL (0x77590000)
        ADVAPI32.dll => /c/windows/system32/ADVAPI32.dll (0x7fefd6e0000)
        msvcrt.dll => /c/windows/system32/msvcrt.dll (0x7fefe0f0000)
        sechost.dll => /c/windows/SYSTEM32/sechost.dll (0x7fefdbd0000)
        RPCRT4.dll => /c/windows/system32/RPCRT4.dll (0x7fefdfc0000)
        IPHLPAPI.DLL => /c/windows/system32/IPHLPAPI.DLL (0x7fefa2c0000)
        NSI.dll => /c/windows/system32/NSI.dll (0x7fefd810000)
        WINNSI.DLL => /c/windows/system32/WINNSI.DLL (0x7fefa2a0000)
        libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x64940000)
        USER32.dll => /c/windows/system32/USER32.dll (0x772c0000)
        GDI32.dll => /c/windows/system32/GDI32.dll (0x7fefe1e0000)
        LPK.dll => /c/windows/system32/LPK.dll (0x7fefe4e0000)
        USP10.dll => /c/windows/system32/USP10.dll (0x7fefe5d0000)
        WS2_32.dll => /c/windows/system32/WS2_32.dll (0x7fefd7c0000)
        WSOCK32.dll => /c/windows/system32/WSOCK32.dll (0x7fef00b0000)
        IMM32.DLL => /c/windows/system32/IMM32.DLL (0x7fefe1b0000)
        MSCTF.dll => /c/windows/system32/MSCTF.dll (0x7fefe830000)


2016-04-19 11:39 GMT+02:00 Michael Gogins :
> What are the results of running ldd on both versions of osc.dll?
>
> Regards,
> Mike
>
> On Apr 19, 2016 2:57 AM, "Oeyvind Brandtsegg" 
> wrote:
>>
>> I don't know the fine details about the technicalities of this, but I
>> can confirm that osc.dll was built and working in the Csound version I
>> built March 7th. I tested this again just now. Open Sound Control also
>> confirmed working in this version. To me, this seems like a strong
>> indicator that it is indeed possible to build osc.dll without getting
>> the libpthread dependency. This version does not complain about any
>> missing dlls, whereas the more recent ones show an error dialog at
>> startup (unless the dlls are distributed in the csound/bin folder).
>> I think it is *very* important we get this sorted out, as it will mean
>> the different frontends and other ways of acessing Csound will
>> otherwise interfere in unpredictable ways,
>>
>>
>> 2016-04-19 2:27 GMT+02:00 Michael Gogins :
>> > LIblo requires pthreads. And that is in fact the source of this
>> > dependency as far as I can tell. I think the build recipe for liblo
>> > could be changed to use a static version of pthreads, however.
>> >
>> > By the way, I am not sure the static build idea is required for
>> > Csound. I was able to run CsoundVST about a year ago with Reaper in
>> > spite of DLL conflicts by ensuring that all DLLs required by Csound
>> > were in the VST bin directory.
>> >
>> > There also now appears to be a new crash in CsoundQt realted to the
>> > Csound MIDI module.
>> >
>> > The other issue I am looking at is a problem with line endings in
>> > CsoundQt. No matter what the number of line endings for each line
>> > keeps increasing, and it's impossible to turn off the Windows line
>> > endings. I think I should be able to fix this one though.
>> >
>> > Best,
>> > Mike
>> >
>> >
>> >
>> >
>> >
>> > -----------------------------------------------------
>> > Michael Gogins
>> > Irreducible Productions
>> > http://michaelgogins.tumblr.com
>> > Michael dot Gogins at gmail dot com
>> >
>> >
>> > On Mon, Apr 18, 2016 at 6:53 PM, Steven Yi  wrote:
>> >> Btw: we used to have separate thread implementations. We switched to
>> >> pthreads, but perhaps this was a mistake and we should have kept the
>> >> implementations but reduced it down to just pthreads, win32, and no-op.
>> >> If
>> >> liblo requires pthreads though, not much to do there about that.
>> >>
>> >>
>> >> On Mon, Apr 18, 2016 at 6:46 PM Steven Yi  wrote:
>> >>>
>> >>> Have you looked at the Git history? I haven't been following that
>> >>> closely
>> >>> but the last build I did from yesterday had a problem where the
>> >>> Virtual
>> >>> keyboard didn't send any midi values. I suspect it has to do with
>> >>> recent
>> >>> lock changes, but I am just guessing. Besides these issues, what else
>> >>> is
>> >>> there?
>> >>> On Mon, Apr 18, 2016 at 6:38 PM Rory Walsh  wrote:
>> >>>>
>> >>>> Oeyvind and I have been trying to figure out what happened to the
>> >>>> Windows
>> >>>> build in mid-march which resulted in osc.dll requiring the
>> >>>> lib-pthread .dll
>> >>>> to be present in order to run. It was wasn't like this before then,
>> >>>> but we
>> >>>> can't tell what happened to change it. Anyone have any ideas? I can't
>> >>>> use
>> >>>> the canonical release of Csound lib to build Cabbage because of all
>> >>>> the .dll
>> >>>> dependencies, but I would love if we could still try to ensure as
>> >>>> much of
>> >>>> the plugin opcodes build statically as possible.
>>
>>
>>
>> --
>>
>> 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/
>> http://soundcloud.com/t-emp



-- 

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/

Thanks. Did you use the PKGBUILD script to build osc.dll? If so then we can just revert it.

Best,
Mike

you mean to build liblo?
Yes, maybe that is a thing to try.

2016-04-19 12:29 GMT+02:00 Michael Gogins :
> Thanks. Did you use the PKGBUILD script to build osc.dll? If so then we can
> just revert it.
>
> Best,
> Mike
>
> On Apr 19, 2016 6:00 AM, "Oeyvind Brandtsegg" 
> wrote:
>>
>> Here, the first one is my own build from March 7th, the second one is
>> the Gogins rc2
>>
>> Administrator@HF-31335 MINGW64 /c/Program
>> Files/Csound6_x64_mymars/plugins64
>> $ ldd osc.dll
>>         ntdll.dll => /c/windows/SYSTEM32/ntdll.dll (0x773c0000)
>>         kernel32.dll => /c/windows/system32/kernel32.dll (0x771a0000)
>>         KERNELBASE.dll => /c/windows/system32/KERNELBASE.dll
>> (0x7fefd210000)
>>         fshook64.dll => /c/program files
>> (x86)/f-secure/hips/fshook64.dll (0x737
>>     d0000)
>>         PSAPI.DLL => /c/windows/system32/PSAPI.DLL (0x77590000)
>>         ADVAPI32.dll => /c/windows/system32/ADVAPI32.dll (0x7fefd6e0000)
>>         msvcrt.dll => /c/windows/system32/msvcrt.dll (0x7fefe0f0000)
>>         sechost.dll => /c/windows/SYSTEM32/sechost.dll (0x7fefdbd0000)
>>         RPCRT4.dll => /c/windows/system32/RPCRT4.dll (0x7fefdfc0000)
>>         IPHLPAPI.DLL => /c/windows/system32/IPHLPAPI.DLL (0x7fefa2c0000)
>>         NSI.dll => /c/windows/system32/NSI.dll (0x7fefd810000)
>>         WINNSI.DLL => /c/windows/system32/WINNSI.DLL (0x7fefa2a0000)
>>         USER32.dll => /c/windows/system32/USER32.dll (0x772c0000)
>>         GDI32.dll => /c/windows/system32/GDI32.dll (0x7fefe1e0000)
>>         LPK.dll => /c/windows/system32/LPK.dll (0x7fefe4e0000)
>>         USP10.dll => /c/windows/system32/USP10.dll (0x7fefe5d0000)
>>         WS2_32.dll => /c/windows/system32/WS2_32.dll (0x7fefd7c0000)
>>         WSOCK32.dll => /c/windows/system32/WSOCK32.dll (0x7fef00b0000)
>>         IMM32.DLL => /c/windows/system32/IMM32.DLL (0x7fefe1b0000)
>>         MSCTF.dll => /c/windows/system32/MSCTF.dll (0x7fefe830000)
>>
>>
>> Administrator@HF-31335 MINGW64 /c/Program Files/Csound6_x64/plugins64
>> $ ldd osc.dll
>>         ntdll.dll => /c/windows/SYSTEM32/ntdll.dll (0x773c0000)
>>         kernel32.dll => /c/windows/system32/kernel32.dll (0x771a0000)
>>         KERNELBASE.dll => /c/windows/system32/KERNELBASE.dll
>> (0x7fefd210000)
>>         fshook64.dll => /c/program files
>> (x86)/f-secure/hips/fshook64.dll (0x737d0000)
>>         PSAPI.DLL => /c/windows/system32/PSAPI.DLL (0x77590000)
>>         ADVAPI32.dll => /c/windows/system32/ADVAPI32.dll (0x7fefd6e0000)
>>         msvcrt.dll => /c/windows/system32/msvcrt.dll (0x7fefe0f0000)
>>         sechost.dll => /c/windows/SYSTEM32/sechost.dll (0x7fefdbd0000)
>>         RPCRT4.dll => /c/windows/system32/RPCRT4.dll (0x7fefdfc0000)
>>         IPHLPAPI.DLL => /c/windows/system32/IPHLPAPI.DLL (0x7fefa2c0000)
>>         NSI.dll => /c/windows/system32/NSI.dll (0x7fefd810000)
>>         WINNSI.DLL => /c/windows/system32/WINNSI.DLL (0x7fefa2a0000)
>>         libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll
>> (0x64940000)
>>         USER32.dll => /c/windows/system32/USER32.dll (0x772c0000)
>>         GDI32.dll => /c/windows/system32/GDI32.dll (0x7fefe1e0000)
>>         LPK.dll => /c/windows/system32/LPK.dll (0x7fefe4e0000)
>>         USP10.dll => /c/windows/system32/USP10.dll (0x7fefe5d0000)
>>         WS2_32.dll => /c/windows/system32/WS2_32.dll (0x7fefd7c0000)
>>         WSOCK32.dll => /c/windows/system32/WSOCK32.dll (0x7fef00b0000)
>>         IMM32.DLL => /c/windows/system32/IMM32.DLL (0x7fefe1b0000)
>>         MSCTF.dll => /c/windows/system32/MSCTF.dll (0x7fefe830000)
>>
>>
>> 2016-04-19 11:39 GMT+02:00 Michael Gogins :
>> > What are the results of running ldd on both versions of osc.dll?
>> >
>> > Regards,
>> > Mike
>> >
>> > On Apr 19, 2016 2:57 AM, "Oeyvind Brandtsegg"
>> > 
>> > wrote:
>> >>
>> >> I don't know the fine details about the technicalities of this, but I
>> >> can confirm that osc.dll was built and working in the Csound version I
>> >> built March 7th. I tested this again just now. Open Sound Control also
>> >> confirmed working in this version. To me, this seems like a strong
>> >> indicator that it is indeed possible to build osc.dll without getting
>> >> the libpthread dependency. This version does not complain about any
>> >> missing dlls, whereas the more recent ones show an error dialog at
>> >> startup (unless the dlls are distributed in the csound/bin folder).
>> >> I think it is *very* important we get this sorted out, as it will mean
>> >> the different frontends and other ways of acessing Csound will
>> >> otherwise interfere in unpredictable ways,
>> >>
>> >>
>> >> 2016-04-19 2:27 GMT+02:00 Michael Gogins :
>> >> > LIblo requires pthreads. And that is in fact the source of this
>> >> > dependency as far as I can tell. I think the build recipe for liblo
>> >> > could be changed to use a static version of pthreads, however.
>> >> >
>> >> > By the way, I am not sure the static build idea is required for
>> >> > Csound. I was able to run CsoundVST about a year ago with Reaper in
>> >> > spite of DLL conflicts by ensuring that all DLLs required by Csound
>> >> > were in the VST bin directory.
>> >> >
>> >> > There also now appears to be a new crash in CsoundQt realted to the
>> >> > Csound MIDI module.
>> >> >
>> >> > The other issue I am looking at is a problem with line endings in
>> >> > CsoundQt. No matter what the number of line endings for each line
>> >> > keeps increasing, and it's impossible to turn off the Windows line
>> >> > endings. I think I should be able to fix this one though.
>> >> >
>> >> > Best,
>> >> > Mike
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > -----------------------------------------------------
>> >> > Michael Gogins
>> >> > Irreducible Productions
>> >> > http://michaelgogins.tumblr.com
>> >> > Michael dot Gogins at gmail dot com
>> >> >
>> >> >
>> >> > On Mon, Apr 18, 2016 at 6:53 PM, Steven Yi 
>> >> > wrote:
>> >> >> Btw: we used to have separate thread implementations. We switched to
>> >> >> pthreads, but perhaps this was a mistake and we should have kept the
>> >> >> implementations but reduced it down to just pthreads, win32, and
>> >> >> no-op.
>> >> >> If
>> >> >> liblo requires pthreads though, not much to do there about that.
>> >> >>
>> >> >>
>> >> >> On Mon, Apr 18, 2016 at 6:46 PM Steven Yi 
>> >> >> wrote:
>> >> >>>
>> >> >>> Have you looked at the Git history? I haven't been following that
>> >> >>> closely
>> >> >>> but the last build I did from yesterday had a problem where the
>> >> >>> Virtual
>> >> >>> keyboard didn't send any midi values. I suspect it has to do with
>> >> >>> recent
>> >> >>> lock changes, but I am just guessing. Besides these issues, what
>> >> >>> else
>> >> >>> is
>> >> >>> there?
>> >> >>> On Mon, Apr 18, 2016 at 6:38 PM Rory Walsh 
>> >> >>> wrote:
>> >> >>>>
>> >> >>>> Oeyvind and I have been trying to figure out what happened to the
>> >> >>>> Windows
>> >> >>>> build in mid-march which resulted in osc.dll requiring the
>> >> >>>> lib-pthread .dll
>> >> >>>> to be present in order to run. It was wasn't like this before
>> >> >>>> then,
>> >> >>>> but we
>> >> >>>> can't tell what happened to change it. Anyone have any ideas? I
>> >> >>>> can't
>> >> >>>> use
>> >> >>>> the canonical release of Csound lib to build Cabbage because of
>> >> >>>> all
>> >> >>>> the .dll
>> >> >>>> dependencies, but I would love if we could still try to ensure as
>> >> >>>> much of
>> >> >>>> the plugin opcodes build statically as possible.
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> 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/
>> >> http://soundcloud.com/t-emp
>>
>>
>>
>> --
>>
>> 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/
>> http://soundcloud.com/t-emp



-- 

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 checked the history for liblo/PKGBUILD and it has not changed,
so I guess the issue is rooted somewwhere else

2016-04-19 12:35 GMT+02:00 Oeyvind Brandtsegg :
> you mean to build liblo?
> Yes, maybe that is a thing to try.
>
> 2016-04-19 12:29 GMT+02:00 Michael Gogins :
>> Thanks. Did you use the PKGBUILD script to build osc.dll? If so then we can
>> just revert it.
>>
>> Best,
>> Mike
>>
>> On Apr 19, 2016 6:00 AM, "Oeyvind Brandtsegg" 
>> wrote:
>>>
>>> Here, the first one is my own build from March 7th, the second one is
>>> the Gogins rc2
>>>
>>> Administrator@HF-31335 MINGW64 /c/Program
>>> Files/Csound6_x64_mymars/plugins64
>>> $ ldd osc.dll
>>>         ntdll.dll => /c/windows/SYSTEM32/ntdll.dll (0x773c0000)
>>>         kernel32.dll => /c/windows/system32/kernel32.dll (0x771a0000)
>>>         KERNELBASE.dll => /c/windows/system32/KERNELBASE.dll
>>> (0x7fefd210000)
>>>         fshook64.dll => /c/program files
>>> (x86)/f-secure/hips/fshook64.dll (0x737
>>>     d0000)
>>>         PSAPI.DLL => /c/windows/system32/PSAPI.DLL (0x77590000)
>>>         ADVAPI32.dll => /c/windows/system32/ADVAPI32.dll (0x7fefd6e0000)
>>>         msvcrt.dll => /c/windows/system32/msvcrt.dll (0x7fefe0f0000)
>>>         sechost.dll => /c/windows/SYSTEM32/sechost.dll (0x7fefdbd0000)
>>>         RPCRT4.dll => /c/windows/system32/RPCRT4.dll (0x7fefdfc0000)
>>>         IPHLPAPI.DLL => /c/windows/system32/IPHLPAPI.DLL (0x7fefa2c0000)
>>>         NSI.dll => /c/windows/system32/NSI.dll (0x7fefd810000)
>>>         WINNSI.DLL => /c/windows/system32/WINNSI.DLL (0x7fefa2a0000)
>>>         USER32.dll => /c/windows/system32/USER32.dll (0x772c0000)
>>>         GDI32.dll => /c/windows/system32/GDI32.dll (0x7fefe1e0000)
>>>         LPK.dll => /c/windows/system32/LPK.dll (0x7fefe4e0000)
>>>         USP10.dll => /c/windows/system32/USP10.dll (0x7fefe5d0000)
>>>         WS2_32.dll => /c/windows/system32/WS2_32.dll (0x7fefd7c0000)
>>>         WSOCK32.dll => /c/windows/system32/WSOCK32.dll (0x7fef00b0000)
>>>         IMM32.DLL => /c/windows/system32/IMM32.DLL (0x7fefe1b0000)
>>>         MSCTF.dll => /c/windows/system32/MSCTF.dll (0x7fefe830000)
>>>
>>>
>>> Administrator@HF-31335 MINGW64 /c/Program Files/Csound6_x64/plugins64
>>> $ ldd osc.dll
>>>         ntdll.dll => /c/windows/SYSTEM32/ntdll.dll (0x773c0000)
>>>         kernel32.dll => /c/windows/system32/kernel32.dll (0x771a0000)
>>>         KERNELBASE.dll => /c/windows/system32/KERNELBASE.dll
>>> (0x7fefd210000)
>>>         fshook64.dll => /c/program files
>>> (x86)/f-secure/hips/fshook64.dll (0x737d0000)
>>>         PSAPI.DLL => /c/windows/system32/PSAPI.DLL (0x77590000)
>>>         ADVAPI32.dll => /c/windows/system32/ADVAPI32.dll (0x7fefd6e0000)
>>>         msvcrt.dll => /c/windows/system32/msvcrt.dll (0x7fefe0f0000)
>>>         sechost.dll => /c/windows/SYSTEM32/sechost.dll (0x7fefdbd0000)
>>>         RPCRT4.dll => /c/windows/system32/RPCRT4.dll (0x7fefdfc0000)
>>>         IPHLPAPI.DLL => /c/windows/system32/IPHLPAPI.DLL (0x7fefa2c0000)
>>>         NSI.dll => /c/windows/system32/NSI.dll (0x7fefd810000)
>>>         WINNSI.DLL => /c/windows/system32/WINNSI.DLL (0x7fefa2a0000)
>>>         libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll
>>> (0x64940000)
>>>         USER32.dll => /c/windows/system32/USER32.dll (0x772c0000)
>>>         GDI32.dll => /c/windows/system32/GDI32.dll (0x7fefe1e0000)
>>>         LPK.dll => /c/windows/system32/LPK.dll (0x7fefe4e0000)
>>>         USP10.dll => /c/windows/system32/USP10.dll (0x7fefe5d0000)
>>>         WS2_32.dll => /c/windows/system32/WS2_32.dll (0x7fefd7c0000)
>>>         WSOCK32.dll => /c/windows/system32/WSOCK32.dll (0x7fef00b0000)
>>>         IMM32.DLL => /c/windows/system32/IMM32.DLL (0x7fefe1b0000)
>>>         MSCTF.dll => /c/windows/system32/MSCTF.dll (0x7fefe830000)
>>>
>>>
>>> 2016-04-19 11:39 GMT+02:00 Michael Gogins :
>>> > What are the results of running ldd on both versions of osc.dll?
>>> >
>>> > Regards,
>>> > Mike
>>> >
>>> > On Apr 19, 2016 2:57 AM, "Oeyvind Brandtsegg"
>>> > 
>>> > wrote:
>>> >>
>>> >> I don't know the fine details about the technicalities of this, but I
>>> >> can confirm that osc.dll was built and working in the Csound version I
>>> >> built March 7th. I tested this again just now. Open Sound Control also
>>> >> confirmed working in this version. To me, this seems like a strong
>>> >> indicator that it is indeed possible to build osc.dll without getting
>>> >> the libpthread dependency. This version does not complain about any
>>> >> missing dlls, whereas the more recent ones show an error dialog at
>>> >> startup (unless the dlls are distributed in the csound/bin folder).
>>> >> I think it is *very* important we get this sorted out, as it will mean
>>> >> the different frontends and other ways of acessing Csound will
>>> >> otherwise interfere in unpredictable ways,
>>> >>
>>> >>
>>> >> 2016-04-19 2:27 GMT+02:00 Michael Gogins :
>>> >> > LIblo requires pthreads. And that is in fact the source of this
>>> >> > dependency as far as I can tell. I think the build recipe for liblo
>>> >> > could be changed to use a static version of pthreads, however.
>>> >> >
>>> >> > By the way, I am not sure the static build idea is required for
>>> >> > Csound. I was able to run CsoundVST about a year ago with Reaper in
>>> >> > spite of DLL conflicts by ensuring that all DLLs required by Csound
>>> >> > were in the VST bin directory.
>>> >> >
>>> >> > There also now appears to be a new crash in CsoundQt realted to the
>>> >> > Csound MIDI module.
>>> >> >
>>> >> > The other issue I am looking at is a problem with line endings in
>>> >> > CsoundQt. No matter what the number of line endings for each line
>>> >> > keeps increasing, and it's impossible to turn off the Windows line
>>> >> > endings. I think I should be able to fix this one though.
>>> >> >
>>> >> > Best,
>>> >> > Mike
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > -----------------------------------------------------
>>> >> > Michael Gogins
>>> >> > Irreducible Productions
>>> >> > http://michaelgogins.tumblr.com
>>> >> > Michael dot Gogins at gmail dot com
>>> >> >
>>> >> >
>>> >> > On Mon, Apr 18, 2016 at 6:53 PM, Steven Yi 
>>> >> > wrote:
>>> >> >> Btw: we used to have separate thread implementations. We switched to
>>> >> >> pthreads, but perhaps this was a mistake and we should have kept the
>>> >> >> implementations but reduced it down to just pthreads, win32, and
>>> >> >> no-op.
>>> >> >> If
>>> >> >> liblo requires pthreads though, not much to do there about that.
>>> >> >>
>>> >> >>
>>> >> >> On Mon, Apr 18, 2016 at 6:46 PM Steven Yi 
>>> >> >> wrote:
>>> >> >>>
>>> >> >>> Have you looked at the Git history? I haven't been following that
>>> >> >>> closely
>>> >> >>> but the last build I did from yesterday had a problem where the
>>> >> >>> Virtual
>>> >> >>> keyboard didn't send any midi values. I suspect it has to do with
>>> >> >>> recent
>>> >> >>> lock changes, but I am just guessing. Besides these issues, what
>>> >> >>> else
>>> >> >>> is
>>> >> >>> there?
>>> >> >>> On Mon, Apr 18, 2016 at 6:38 PM Rory Walsh 
>>> >> >>> wrote:
>>> >> >>>>
>>> >> >>>> Oeyvind and I have been trying to figure out what happened to the
>>> >> >>>> Windows
>>> >> >>>> build in mid-march which resulted in osc.dll requiring the
>>> >> >>>> lib-pthread .dll
>>> >> >>>> to be present in order to run. It was wasn't like this before
>>> >> >>>> then,
>>> >> >>>> but we
>>> >> >>>> can't tell what happened to change it. Anyone have any ideas? I
>>> >> >>>> can't
>>> >> >>>> use
>>> >> >>>> the canonical release of Csound lib to build Cabbage because of
>>> >> >>>> all
>>> >> >>>> the .dll
>>> >> >>>> dependencies, but I would love if we could still try to ensure as
>>> >> >>>> much of
>>> >> >>>> the plugin opcodes build statically as possible.
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >>
>>> >> 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/
>>> >> http://soundcloud.com/t-emp
>>>
>>>
>>>
>>> --
>>>
>>> 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/
>>> http://soundcloud.com/t-emp
>
>
>
> --
>
> 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/
> http://soundcloud.com/t-emp



-- 

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/

Very strange. Perhaps you built it some other way.

Best,
Mike

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


On Tue, Apr 19, 2016 at 6:51 AM, Oeyvind Brandtsegg
 wrote:
> ... I checked the history for liblo/PKGBUILD and it has not changed,
> so I guess the issue is rooted somewwhere else
>
> 2016-04-19 12:35 GMT+02:00 Oeyvind Brandtsegg :
>> you mean to build liblo?
>> Yes, maybe that is a thing to try.
>>
>> 2016-04-19 12:29 GMT+02:00 Michael Gogins :
>>> Thanks. Did you use the PKGBUILD script to build osc.dll? If so then we can
>>> just revert it.
>>>
>>> Best,
>>> Mike
>>>
>>> On Apr 19, 2016 6:00 AM, "Oeyvind Brandtsegg" 
>>> wrote:
>>>>
>>>> Here, the first one is my own build from March 7th, the second one is
>>>> the Gogins rc2
>>>>
>>>> Administrator@HF-31335 MINGW64 /c/Program
>>>> Files/Csound6_x64_mymars/plugins64
>>>> $ ldd osc.dll
>>>>         ntdll.dll => /c/windows/SYSTEM32/ntdll.dll (0x773c0000)
>>>>         kernel32.dll => /c/windows/system32/kernel32.dll (0x771a0000)
>>>>         KERNELBASE.dll => /c/windows/system32/KERNELBASE.dll
>>>> (0x7fefd210000)
>>>>         fshook64.dll => /c/program files
>>>> (x86)/f-secure/hips/fshook64.dll (0x737
>>>>     d0000)
>>>>         PSAPI.DLL => /c/windows/system32/PSAPI.DLL (0x77590000)
>>>>         ADVAPI32.dll => /c/windows/system32/ADVAPI32.dll (0x7fefd6e0000)
>>>>         msvcrt.dll => /c/windows/system32/msvcrt.dll (0x7fefe0f0000)
>>>>         sechost.dll => /c/windows/SYSTEM32/sechost.dll (0x7fefdbd0000)
>>>>         RPCRT4.dll => /c/windows/system32/RPCRT4.dll (0x7fefdfc0000)
>>>>         IPHLPAPI.DLL => /c/windows/system32/IPHLPAPI.DLL (0x7fefa2c0000)
>>>>         NSI.dll => /c/windows/system32/NSI.dll (0x7fefd810000)
>>>>         WINNSI.DLL => /c/windows/system32/WINNSI.DLL (0x7fefa2a0000)
>>>>         USER32.dll => /c/windows/system32/USER32.dll (0x772c0000)
>>>>         GDI32.dll => /c/windows/system32/GDI32.dll (0x7fefe1e0000)
>>>>         LPK.dll => /c/windows/system32/LPK.dll (0x7fefe4e0000)
>>>>         USP10.dll => /c/windows/system32/USP10.dll (0x7fefe5d0000)
>>>>         WS2_32.dll => /c/windows/system32/WS2_32.dll (0x7fefd7c0000)
>>>>         WSOCK32.dll => /c/windows/system32/WSOCK32.dll (0x7fef00b0000)
>>>>         IMM32.DLL => /c/windows/system32/IMM32.DLL (0x7fefe1b0000)
>>>>         MSCTF.dll => /c/windows/system32/MSCTF.dll (0x7fefe830000)
>>>>
>>>>
>>>> Administrator@HF-31335 MINGW64 /c/Program Files/Csound6_x64/plugins64
>>>> $ ldd osc.dll
>>>>         ntdll.dll => /c/windows/SYSTEM32/ntdll.dll (0x773c0000)
>>>>         kernel32.dll => /c/windows/system32/kernel32.dll (0x771a0000)
>>>>         KERNELBASE.dll => /c/windows/system32/KERNELBASE.dll
>>>> (0x7fefd210000)
>>>>         fshook64.dll => /c/program files
>>>> (x86)/f-secure/hips/fshook64.dll (0x737d0000)
>>>>         PSAPI.DLL => /c/windows/system32/PSAPI.DLL (0x77590000)
>>>>         ADVAPI32.dll => /c/windows/system32/ADVAPI32.dll (0x7fefd6e0000)
>>>>         msvcrt.dll => /c/windows/system32/msvcrt.dll (0x7fefe0f0000)
>>>>         sechost.dll => /c/windows/SYSTEM32/sechost.dll (0x7fefdbd0000)
>>>>         RPCRT4.dll => /c/windows/system32/RPCRT4.dll (0x7fefdfc0000)
>>>>         IPHLPAPI.DLL => /c/windows/system32/IPHLPAPI.DLL (0x7fefa2c0000)
>>>>         NSI.dll => /c/windows/system32/NSI.dll (0x7fefd810000)
>>>>         WINNSI.DLL => /c/windows/system32/WINNSI.DLL (0x7fefa2a0000)
>>>>         libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll
>>>> (0x64940000)
>>>>         USER32.dll => /c/windows/system32/USER32.dll (0x772c0000)
>>>>         GDI32.dll => /c/windows/system32/GDI32.dll (0x7fefe1e0000)
>>>>         LPK.dll => /c/windows/system32/LPK.dll (0x7fefe4e0000)
>>>>         USP10.dll => /c/windows/system32/USP10.dll (0x7fefe5d0000)
>>>>         WS2_32.dll => /c/windows/system32/WS2_32.dll (0x7fefd7c0000)
>>>>         WSOCK32.dll => /c/windows/system32/WSOCK32.dll (0x7fef00b0000)
>>>>         IMM32.DLL => /c/windows/system32/IMM32.DLL (0x7fefe1b0000)
>>>>         MSCTF.dll => /c/windows/system32/MSCTF.dll (0x7fefe830000)
>>>>
>>>>
>>>> 2016-04-19 11:39 GMT+02:00 Michael Gogins :
>>>> > What are the results of running ldd on both versions of osc.dll?
>>>> >
>>>> > Regards,
>>>> > Mike
>>>> >
>>>> > On Apr 19, 2016 2:57 AM, "Oeyvind Brandtsegg"
>>>> > 
>>>> > wrote:
>>>> >>
>>>> >> I don't know the fine details about the technicalities of this, but I
>>>> >> can confirm that osc.dll was built and working in the Csound version I
>>>> >> built March 7th. I tested this again just now. Open Sound Control also
>>>> >> confirmed working in this version. To me, this seems like a strong
>>>> >> indicator that it is indeed possible to build osc.dll without getting
>>>> >> the libpthread dependency. This version does not complain about any
>>>> >> missing dlls, whereas the more recent ones show an error dialog at
>>>> >> startup (unless the dlls are distributed in the csound/bin folder).
>>>> >> I think it is *very* important we get this sorted out, as it will mean
>>>> >> the different frontends and other ways of acessing Csound will
>>>> >> otherwise interfere in unpredictable ways,
>>>> >>
>>>> >>
>>>> >> 2016-04-19 2:27 GMT+02:00 Michael Gogins :
>>>> >> > LIblo requires pthreads. And that is in fact the source of this
>>>> >> > dependency as far as I can tell. I think the build recipe for liblo
>>>> >> > could be changed to use a static version of pthreads, however.
>>>> >> >
>>>> >> > By the way, I am not sure the static build idea is required for
>>>> >> > Csound. I was able to run CsoundVST about a year ago with Reaper in
>>>> >> > spite of DLL conflicts by ensuring that all DLLs required by Csound
>>>> >> > were in the VST bin directory.
>>>> >> >
>>>> >> > There also now appears to be a new crash in CsoundQt realted to the
>>>> >> > Csound MIDI module.
>>>> >> >
>>>> >> > The other issue I am looking at is a problem with line endings in
>>>> >> > CsoundQt. No matter what the number of line endings for each line
>>>> >> > keeps increasing, and it's impossible to turn off the Windows line
>>>> >> > endings. I think I should be able to fix this one though.
>>>> >> >
>>>> >> > Best,
>>>> >> > Mike
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > -----------------------------------------------------
>>>> >> > Michael Gogins
>>>> >> > Irreducible Productions
>>>> >> > http://michaelgogins.tumblr.com
>>>> >> > Michael dot Gogins at gmail dot com
>>>> >> >
>>>> >> >
>>>> >> > On Mon, Apr 18, 2016 at 6:53 PM, Steven Yi 
>>>> >> > wrote:
>>>> >> >> Btw: we used to have separate thread implementations. We switched to
>>>> >> >> pthreads, but perhaps this was a mistake and we should have kept the
>>>> >> >> implementations but reduced it down to just pthreads, win32, and
>>>> >> >> no-op.
>>>> >> >> If
>>>> >> >> liblo requires pthreads though, not much to do there about that.
>>>> >> >>
>>>> >> >>
>>>> >> >> On Mon, Apr 18, 2016 at 6:46 PM Steven Yi 
>>>> >> >> wrote:
>>>> >> >>>
>>>> >> >>> Have you looked at the Git history? I haven't been following that
>>>> >> >>> closely
>>>> >> >>> but the last build I did from yesterday had a problem where the
>>>> >> >>> Virtual
>>>> >> >>> keyboard didn't send any midi values. I suspect it has to do with
>>>> >> >>> recent
>>>> >> >>> lock changes, but I am just guessing. Besides these issues, what
>>>> >> >>> else
>>>> >> >>> is
>>>> >> >>> there?
>>>> >> >>> On Mon, Apr 18, 2016 at 6:38 PM Rory Walsh 
>>>> >> >>> wrote:
>>>> >> >>>>
>>>> >> >>>> Oeyvind and I have been trying to figure out what happened to the
>>>> >> >>>> Windows
>>>> >> >>>> build in mid-march which resulted in osc.dll requiring the
>>>> >> >>>> lib-pthread .dll
>>>> >> >>>> to be present in order to run. It was wasn't like this before
>>>> >> >>>> then,
>>>> >> >>>> but we
>>>> >> >>>> can't tell what happened to change it. Anyone have any ideas? I
>>>> >> >>>> can't
>>>> >> >>>> use
>>>> >> >>>> the canonical release of Csound lib to build Cabbage because of
>>>> >> >>>> all
>>>> >> >>>> the .dll
>>>> >> >>>> dependencies, but I would love if we could still try to ensure as
>>>> >> >>>> much of
>>>> >> >>>> the plugin opcodes build statically as possible.
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >>
>>>> >> 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/
>>>> >> http://soundcloud.com/t-emp
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> 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/
>>>> http://soundcloud.com/t-emp
>>
>>
>>
>> --
>>
>> 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/
>> http://soundcloud.com/t-emp
>
>
>
> --
>
> 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/

No I'm sure I did not.
The build system and the msys2 installation has been used only to
build Csound, set up for that purpose during January/February. I
haven't built anything else. And only build the dependencies in
packages by using pkgbuilds in the csound repo.
Could it be related to another package that was added (to the Csound
repo) sometime during March? I did build and install those.


2016-04-19 13:26 GMT+02:00 Michael Gogins :
> Very strange. Perhaps you built it some other way.
>
> Best,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Tue, Apr 19, 2016 at 6:51 AM, Oeyvind Brandtsegg
>  wrote:
>> ... I checked the history for liblo/PKGBUILD and it has not changed,
>> so I guess the issue is rooted somewwhere else
>>
>> 2016-04-19 12:35 GMT+02:00 Oeyvind Brandtsegg :
>>> you mean to build liblo?
>>> Yes, maybe that is a thing to try.
>>>
>>> 2016-04-19 12:29 GMT+02:00 Michael Gogins :
>>>> Thanks. Did you use the PKGBUILD script to build osc.dll? If so then we can
>>>> just revert it.
>>>>
>>>> Best,
>>>> Mike
>>>>
>>>> On Apr 19, 2016 6:00 AM, "Oeyvind Brandtsegg" 
>>>> wrote:
>>>>>
>>>>> Here, the first one is my own build from March 7th, the second one is
>>>>> the Gogins rc2
>>>>>
>>>>> Administrator@HF-31335 MINGW64 /c/Program
>>>>> Files/Csound6_x64_mymars/plugins64
>>>>> $ ldd osc.dll
>>>>>         ntdll.dll => /c/windows/SYSTEM32/ntdll.dll (0x773c0000)
>>>>>         kernel32.dll => /c/windows/system32/kernel32.dll (0x771a0000)
>>>>>         KERNELBASE.dll => /c/windows/system32/KERNELBASE.dll
>>>>> (0x7fefd210000)
>>>>>         fshook64.dll => /c/program files
>>>>> (x86)/f-secure/hips/fshook64.dll (0x737
>>>>>     d0000)
>>>>>         PSAPI.DLL => /c/windows/system32/PSAPI.DLL (0x77590000)
>>>>>         ADVAPI32.dll => /c/windows/system32/ADVAPI32.dll (0x7fefd6e0000)
>>>>>         msvcrt.dll => /c/windows/system32/msvcrt.dll (0x7fefe0f0000)
>>>>>         sechost.dll => /c/windows/SYSTEM32/sechost.dll (0x7fefdbd0000)
>>>>>         RPCRT4.dll => /c/windows/system32/RPCRT4.dll (0x7fefdfc0000)
>>>>>         IPHLPAPI.DLL => /c/windows/system32/IPHLPAPI.DLL (0x7fefa2c0000)
>>>>>         NSI.dll => /c/windows/system32/NSI.dll (0x7fefd810000)
>>>>>         WINNSI.DLL => /c/windows/system32/WINNSI.DLL (0x7fefa2a0000)
>>>>>         USER32.dll => /c/windows/system32/USER32.dll (0x772c0000)
>>>>>         GDI32.dll => /c/windows/system32/GDI32.dll (0x7fefe1e0000)
>>>>>         LPK.dll => /c/windows/system32/LPK.dll (0x7fefe4e0000)
>>>>>         USP10.dll => /c/windows/system32/USP10.dll (0x7fefe5d0000)
>>>>>         WS2_32.dll => /c/windows/system32/WS2_32.dll (0x7fefd7c0000)
>>>>>         WSOCK32.dll => /c/windows/system32/WSOCK32.dll (0x7fef00b0000)
>>>>>         IMM32.DLL => /c/windows/system32/IMM32.DLL (0x7fefe1b0000)
>>>>>         MSCTF.dll => /c/windows/system32/MSCTF.dll (0x7fefe830000)
>>>>>
>>>>>
>>>>> Administrator@HF-31335 MINGW64 /c/Program Files/Csound6_x64/plugins64
>>>>> $ ldd osc.dll
>>>>>         ntdll.dll => /c/windows/SYSTEM32/ntdll.dll (0x773c0000)
>>>>>         kernel32.dll => /c/windows/system32/kernel32.dll (0x771a0000)
>>>>>         KERNELBASE.dll => /c/windows/system32/KERNELBASE.dll
>>>>> (0x7fefd210000)
>>>>>         fshook64.dll => /c/program files
>>>>> (x86)/f-secure/hips/fshook64.dll (0x737d0000)
>>>>>         PSAPI.DLL => /c/windows/system32/PSAPI.DLL (0x77590000)
>>>>>         ADVAPI32.dll => /c/windows/system32/ADVAPI32.dll (0x7fefd6e0000)
>>>>>         msvcrt.dll => /c/windows/system32/msvcrt.dll (0x7fefe0f0000)
>>>>>         sechost.dll => /c/windows/SYSTEM32/sechost.dll (0x7fefdbd0000)
>>>>>         RPCRT4.dll => /c/windows/system32/RPCRT4.dll (0x7fefdfc0000)
>>>>>         IPHLPAPI.DLL => /c/windows/system32/IPHLPAPI.DLL (0x7fefa2c0000)
>>>>>         NSI.dll => /c/windows/system32/NSI.dll (0x7fefd810000)
>>>>>         WINNSI.DLL => /c/windows/system32/WINNSI.DLL (0x7fefa2a0000)
>>>>>         libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll
>>>>> (0x64940000)
>>>>>         USER32.dll => /c/windows/system32/USER32.dll (0x772c0000)
>>>>>         GDI32.dll => /c/windows/system32/GDI32.dll (0x7fefe1e0000)
>>>>>         LPK.dll => /c/windows/system32/LPK.dll (0x7fefe4e0000)
>>>>>         USP10.dll => /c/windows/system32/USP10.dll (0x7fefe5d0000)
>>>>>         WS2_32.dll => /c/windows/system32/WS2_32.dll (0x7fefd7c0000)
>>>>>         WSOCK32.dll => /c/windows/system32/WSOCK32.dll (0x7fef00b0000)
>>>>>         IMM32.DLL => /c/windows/system32/IMM32.DLL (0x7fefe1b0000)
>>>>>         MSCTF.dll => /c/windows/system32/MSCTF.dll (0x7fefe830000)
>>>>>
>>>>>
>>>>> 2016-04-19 11:39 GMT+02:00 Michael Gogins :
>>>>> > What are the results of running ldd on both versions of osc.dll?
>>>>> >
>>>>> > Regards,
>>>>> > Mike
>>>>> >
>>>>> > On Apr 19, 2016 2:57 AM, "Oeyvind Brandtsegg"
>>>>> > 
>>>>> > wrote:
>>>>> >>
>>>>> >> I don't know the fine details about the technicalities of this, but I
>>>>> >> can confirm that osc.dll was built and working in the Csound version I
>>>>> >> built March 7th. I tested this again just now. Open Sound Control also
>>>>> >> confirmed working in this version. To me, this seems like a strong
>>>>> >> indicator that it is indeed possible to build osc.dll without getting
>>>>> >> the libpthread dependency. This version does not complain about any
>>>>> >> missing dlls, whereas the more recent ones show an error dialog at
>>>>> >> startup (unless the dlls are distributed in the csound/bin folder).
>>>>> >> I think it is *very* important we get this sorted out, as it will mean
>>>>> >> the different frontends and other ways of acessing Csound will
>>>>> >> otherwise interfere in unpredictable ways,
>>>>> >>
>>>>> >>
>>>>> >> 2016-04-19 2:27 GMT+02:00 Michael Gogins :
>>>>> >> > LIblo requires pthreads. And that is in fact the source of this
>>>>> >> > dependency as far as I can tell. I think the build recipe for liblo
>>>>> >> > could be changed to use a static version of pthreads, however.
>>>>> >> >
>>>>> >> > By the way, I am not sure the static build idea is required for
>>>>> >> > Csound. I was able to run CsoundVST about a year ago with Reaper in
>>>>> >> > spite of DLL conflicts by ensuring that all DLLs required by Csound
>>>>> >> > were in the VST bin directory.
>>>>> >> >
>>>>> >> > There also now appears to be a new crash in CsoundQt realted to the
>>>>> >> > Csound MIDI module.
>>>>> >> >
>>>>> >> > The other issue I am looking at is a problem with line endings in
>>>>> >> > CsoundQt. No matter what the number of line endings for each line
>>>>> >> > keeps increasing, and it's impossible to turn off the Windows line
>>>>> >> > endings. I think I should be able to fix this one though.
>>>>> >> >
>>>>> >> > Best,
>>>>> >> > Mike
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > -----------------------------------------------------
>>>>> >> > Michael Gogins
>>>>> >> > Irreducible Productions
>>>>> >> > http://michaelgogins.tumblr.com
>>>>> >> > Michael dot Gogins at gmail dot com
>>>>> >> >
>>>>> >> >
>>>>> >> > On Mon, Apr 18, 2016 at 6:53 PM, Steven Yi 
>>>>> >> > wrote:
>>>>> >> >> Btw: we used to have separate thread implementations. We switched to
>>>>> >> >> pthreads, but perhaps this was a mistake and we should have kept the
>>>>> >> >> implementations but reduced it down to just pthreads, win32, and
>>>>> >> >> no-op.
>>>>> >> >> If
>>>>> >> >> liblo requires pthreads though, not much to do there about that.
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> On Mon, Apr 18, 2016 at 6:46 PM Steven Yi 
>>>>> >> >> wrote:
>>>>> >> >>>
>>>>> >> >>> Have you looked at the Git history? I haven't been following that
>>>>> >> >>> closely
>>>>> >> >>> but the last build I did from yesterday had a problem where the
>>>>> >> >>> Virtual
>>>>> >> >>> keyboard didn't send any midi values. I suspect it has to do with
>>>>> >> >>> recent
>>>>> >> >>> lock changes, but I am just guessing. Besides these issues, what
>>>>> >> >>> else
>>>>> >> >>> is
>>>>> >> >>> there?
>>>>> >> >>> On Mon, Apr 18, 2016 at 6:38 PM Rory Walsh 
>>>>> >> >>> wrote:
>>>>> >> >>>>
>>>>> >> >>>> Oeyvind and I have been trying to figure out what happened to the
>>>>> >> >>>> Windows
>>>>> >> >>>> build in mid-march which resulted in osc.dll requiring the
>>>>> >> >>>> lib-pthread .dll
>>>>> >> >>>> to be present in order to run. It was wasn't like this before
>>>>> >> >>>> then,
>>>>> >> >>>> but we
>>>>> >> >>>> can't tell what happened to change it. Anyone have any ideas? I
>>>>> >> >>>> can't
>>>>> >> >>>> use
>>>>> >> >>>> the canonical release of Csound lib to build Cabbage because of
>>>>> >> >>>> all
>>>>> >> >>>> the .dll
>>>>> >> >>>> dependencies, but I would love if we could still try to ensure as
>>>>> >> >>>> much of
>>>>> >> >>>> the plugin opcodes build statically as possible.
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >>
>>>>> >> 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/
>>>>> >> http://soundcloud.com/t-emp
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> 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/
>>>>> http://soundcloud.com/t-emp
>>>
>>>
>>>
>>> --
>>>
>>> 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/
>>> http://soundcloud.com/t-emp
>>
>>
>>
>> --
>>
>> 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/
>> http://soundcloud.com/t-emp



-- 

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'm looking at this now. Just FYI, my liblo build here has no winpthread:

$ ldd liblo-7.dll
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd2fe20000)
        KERNEL32.DLL => /c/WINDOWS/system32/KERNEL32.DLL (0x7ffd2d9c0000)
        KERNELBASE.dll => /c/WINDOWS/system32/KERNELBASE.dll (0x7ffd2cfd0000)
        apphelp.dll => /c/WINDOWS/system32/apphelp.dll (0x7ffd2ac30000)
        msvcrt.dll => /c/WINDOWS/system32/msvcrt.dll (0x7ffd2d6e0000)

and neither does my osc.dll:


$ ldd osc.dll
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd2fe20000)
        KERNEL32.DLL => /c/WINDOWS/system32/KERNEL32.DLL (0x7ffd2d9c0000)
        KERNELBASE.dll => /c/WINDOWS/system32/KERNELBASE.dll (0x7ffd2cfd0000)
        msvcrt.dll => /c/WINDOWS/system32/msvcrt.dll (0x7ffd2d6e0000)

The liblo build is from January 14th. The osc.dll build is from April
11th. Then again, my build also doesn't even load the osc.dll opcode
library:


'C:\Users\stevenyi\work\csound\csound\mingw64\csound-mingw64\stkops.dll'
(-1)WARNING: could not open library
'C:\Users\stevenyi\work\csound\csound\mingw64\csound-mingw64\osc.dll'
(-1)

I am not sure what is going on now.

On Tue, Apr 19, 2016 at 8:00 AM, Rory Walsh  wrote:
> Exact same results here. I did look thought the git commit history, and the
> only thing that really changed in the plugin CmakeLists.txt was the addition
> of some extra "find modules" stuff:
> https://github.com/csound/csound/commit/1d94318cf828e045c6c768889c55e467f1055d06
> I think up to this point OSC.dll was still linking statically to pthread.
> Oeyvind, have you tried using the CMakelists.txt file from the 7th of March
> with the latest dev branch? Does it work?
>
> On 19 April 2016 at 12:35, Oeyvind Brandtsegg 
> wrote:
>>
>> No I'm sure I did not.
>> The build system and the msys2 installation has been used only to
>> build Csound, set up for that purpose during January/February. I
>> haven't built anything else. And only build the dependencies in
>> packages by using pkgbuilds in the csound repo.
>> Could it be related to another package that was added (to the Csound
>> repo) sometime during March? I did build and install those.
>>
>>
>> 2016-04-19 13:26 GMT+02:00 Michael Gogins :
>> > Very strange. Perhaps you built it some other way.
>> >
>> > Best,
>> > Mike
>> >
>> > -----------------------------------------------------
>> > Michael Gogins
>> > Irreducible Productions
>> > http://michaelgogins.tumblr.com
>> > Michael dot Gogins at gmail dot com
>> >
>> >
>> > On Tue, Apr 19, 2016 at 6:51 AM, Oeyvind Brandtsegg
>> >  wrote:
>> >> ... I checked the history for liblo/PKGBUILD and it has not changed,
>> >> so I guess the issue is rooted somewwhere else
>> >>
>> >> 2016-04-19 12:35 GMT+02:00 Oeyvind Brandtsegg
>> >> :
>> >>> you mean to build liblo?
>> >>> Yes, maybe that is a thing to try.
>> >>>
>> >>> 2016-04-19 12:29 GMT+02:00 Michael Gogins :
>> >>>> Thanks. Did you use the PKGBUILD script to build osc.dll? If so then
>> >>>> we can
>> >>>> just revert it.
>> >>>>
>> >>>> Best,
>> >>>> Mike
>> >>>>
>> >>>> On Apr 19, 2016 6:00 AM, "Oeyvind Brandtsegg"
>> >>>> 
>> >>>> wrote:
>> >>>>>
>> >>>>> Here, the first one is my own build from March 7th, the second one
>> >>>>> is
>> >>>>> the Gogins rc2
>> >>>>>
>> >>>>> Administrator@HF-31335 MINGW64 /c/Program
>> >>>>> Files/Csound6_x64_mymars/plugins64
>> >>>>> $ ldd osc.dll
>> >>>>>         ntdll.dll => /c/windows/SYSTEM32/ntdll.dll (0x773c0000)
>> >>>>>         kernel32.dll => /c/windows/system32/kernel32.dll
>> >>>>> (0x771a0000)
>> >>>>>         KERNELBASE.dll => /c/windows/system32/KERNELBASE.dll
>> >>>>> (0x7fefd210000)
>> >>>>>         fshook64.dll => /c/program files
>> >>>>> (x86)/f-secure/hips/fshook64.dll (0x737
>> >>>>>     d0000)
>> >>>>>         PSAPI.DLL => /c/windows/system32/PSAPI.DLL (0x77590000)
>> >>>>>         ADVAPI32.dll => /c/windows/system32/ADVAPI32.dll
>> >>>>> (0x7fefd6e0000)
>> >>>>>         msvcrt.dll => /c/windows/system32/msvcrt.dll (0x7fefe0f0000)
>> >>>>>         sechost.dll => /c/windows/SYSTEM32/sechost.dll
>> >>>>> (0x7fefdbd0000)
>> >>>>>         RPCRT4.dll => /c/windows/system32/RPCRT4.dll (0x7fefdfc0000)
>> >>>>>         IPHLPAPI.DLL => /c/windows/system32/IPHLPAPI.DLL
>> >>>>> (0x7fefa2c0000)
>> >>>>>         NSI.dll => /c/windows/system32/NSI.dll (0x7fefd810000)
>> >>>>>         WINNSI.DLL => /c/windows/system32/WINNSI.DLL (0x7fefa2a0000)
>> >>>>>         USER32.dll => /c/windows/system32/USER32.dll (0x772c0000)
>> >>>>>         GDI32.dll => /c/windows/system32/GDI32.dll (0x7fefe1e0000)
>> >>>>>         LPK.dll => /c/windows/system32/LPK.dll (0x7fefe4e0000)
>> >>>>>         USP10.dll => /c/windows/system32/USP10.dll (0x7fefe5d0000)
>> >>>>>         WS2_32.dll => /c/windows/system32/WS2_32.dll (0x7fefd7c0000)
>> >>>>>         WSOCK32.dll => /c/windows/system32/WSOCK32.dll
>> >>>>> (0x7fef00b0000)
>> >>>>>         IMM32.DLL => /c/windows/system32/IMM32.DLL (0x7fefe1b0000)
>> >>>>>         MSCTF.dll => /c/windows/system32/MSCTF.dll (0x7fefe830000)
>> >>>>>
>> >>>>>
>> >>>>> Administrator@HF-31335 MINGW64 /c/Program
>> >>>>> Files/Csound6_x64/plugins64
>> >>>>> $ ldd osc.dll
>> >>>>>         ntdll.dll => /c/windows/SYSTEM32/ntdll.dll (0x773c0000)
>> >>>>>         kernel32.dll => /c/windows/system32/kernel32.dll
>> >>>>> (0x771a0000)
>> >>>>>         KERNELBASE.dll => /c/windows/system32/KERNELBASE.dll
>> >>>>> (0x7fefd210000)
>> >>>>>         fshook64.dll => /c/program files
>> >>>>> (x86)/f-secure/hips/fshook64.dll (0x737d0000)
>> >>>>>         PSAPI.DLL => /c/windows/system32/PSAPI.DLL (0x77590000)
>> >>>>>         ADVAPI32.dll => /c/windows/system32/ADVAPI32.dll
>> >>>>> (0x7fefd6e0000)
>> >>>>>         msvcrt.dll => /c/windows/system32/msvcrt.dll (0x7fefe0f0000)
>> >>>>>         sechost.dll => /c/windows/SYSTEM32/sechost.dll
>> >>>>> (0x7fefdbd0000)
>> >>>>>         RPCRT4.dll => /c/windows/system32/RPCRT4.dll (0x7fefdfc0000)
>> >>>>>         IPHLPAPI.DLL => /c/windows/system32/IPHLPAPI.DLL
>> >>>>> (0x7fefa2c0000)
>> >>>>>         NSI.dll => /c/windows/system32/NSI.dll (0x7fefd810000)
>> >>>>>         WINNSI.DLL => /c/windows/system32/WINNSI.DLL (0x7fefa2a0000)
>> >>>>>         libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll
>> >>>>> (0x64940000)
>> >>>>>         USER32.dll => /c/windows/system32/USER32.dll (0x772c0000)
>> >>>>>         GDI32.dll => /c/windows/system32/GDI32.dll (0x7fefe1e0000)
>> >>>>>         LPK.dll => /c/windows/system32/LPK.dll (0x7fefe4e0000)
>> >>>>>         USP10.dll => /c/windows/system32/USP10.dll (0x7fefe5d0000)
>> >>>>>         WS2_32.dll => /c/windows/system32/WS2_32.dll (0x7fefd7c0000)
>> >>>>>         WSOCK32.dll => /c/windows/system32/WSOCK32.dll
>> >>>>> (0x7fef00b0000)
>> >>>>>         IMM32.DLL => /c/windows/system32/IMM32.DLL (0x7fefe1b0000)
>> >>>>>         MSCTF.dll => /c/windows/system32/MSCTF.dll (0x7fefe830000)
>> >>>>>
>> >>>>>
>> >>>>> 2016-04-19 11:39 GMT+02:00 Michael Gogins
>> >>>>> :
>> >>>>> > What are the results of running ldd on both versions of osc.dll?
>> >>>>> >
>> >>>>> > Regards,
>> >>>>> > Mike
>> >>>>> >
>> >>>>> > On Apr 19, 2016 2:57 AM, "Oeyvind Brandtsegg"
>> >>>>> > 
>> >>>>> > wrote:
>> >>>>> >>
>> >>>>> >> I don't know the fine details about the technicalities of this,
>> >>>>> >> but I
>> >>>>> >> can confirm that osc.dll was built and working in the Csound
>> >>>>> >> version I
>> >>>>> >> built March 7th. I tested this again just now. Open Sound Control
>> >>>>> >> also
>> >>>>> >> confirmed working in this version. To me, this seems like a
>> >>>>> >> strong
>> >>>>> >> indicator that it is indeed possible to build osc.dll without
>> >>>>> >> getting
>> >>>>> >> the libpthread dependency. This version does not complain about
>> >>>>> >> any
>> >>>>> >> missing dlls, whereas the more recent ones show an error dialog
>> >>>>> >> at
>> >>>>> >> startup (unless the dlls are distributed in the csound/bin
>> >>>>> >> folder).
>> >>>>> >> I think it is *very* important we get this sorted out, as it will
>> >>>>> >> mean
>> >>>>> >> the different frontends and other ways of acessing Csound will
>> >>>>> >> otherwise interfere in unpredictable ways,
>> >>>>> >>
>> >>>>> >>
>> >>>>> >> 2016-04-19 2:27 GMT+02:00 Michael Gogins
>> >>>>> >> :
>> >>>>> >> > LIblo requires pthreads. And that is in fact the source of this
>> >>>>> >> > dependency as far as I can tell. I think the build recipe for
>> >>>>> >> > liblo
>> >>>>> >> > could be changed to use a static version of pthreads, however.
>> >>>>> >> >
>> >>>>> >> > By the way, I am not sure the static build idea is required for
>> >>>>> >> > Csound. I was able to run CsoundVST about a year ago with
>> >>>>> >> > Reaper in
>> >>>>> >> > spite of DLL conflicts by ensuring that all DLLs required by
>> >>>>> >> > Csound
>> >>>>> >> > were in the VST bin directory.
>> >>>>> >> >
>> >>>>> >> > There also now appears to be a new crash in CsoundQt realted to
>> >>>>> >> > the
>> >>>>> >> > Csound MIDI module.
>> >>>>> >> >
>> >>>>> >> > The other issue I am looking at is a problem with line endings
>> >>>>> >> > in
>> >>>>> >> > CsoundQt. No matter what the number of line endings for each
>> >>>>> >> > line
>> >>>>> >> > keeps increasing, and it's impossible to turn off the Windows
>> >>>>> >> > line
>> >>>>> >> > endings. I think I should be able to fix this one though.
>> >>>>> >> >
>> >>>>> >> > Best,
>> >>>>> >> > Mike
>> >>>>> >> >
>> >>>>> >> >
>> >>>>> >> >
>> >>>>> >> >
>> >>>>> >> >
>> >>>>> >> > -----------------------------------------------------
>> >>>>> >> > Michael Gogins
>> >>>>> >> > Irreducible Productions
>> >>>>> >> > http://michaelgogins.tumblr.com
>> >>>>> >> > Michael dot Gogins at gmail dot com
>> >>>>> >> >
>> >>>>> >> >
>> >>>>> >> > On Mon, Apr 18, 2016 at 6:53 PM, Steven Yi 
>> >>>>> >> > wrote:
>> >>>>> >> >> Btw: we used to have separate thread implementations. We
>> >>>>> >> >> switched to
>> >>>>> >> >> pthreads, but perhaps this was a mistake and we should have
>> >>>>> >> >> kept the
>> >>>>> >> >> implementations but reduced it down to just pthreads, win32,
>> >>>>> >> >> and
>> >>>>> >> >> no-op.
>> >>>>> >> >> If
>> >>>>> >> >> liblo requires pthreads though, not much to do there about
>> >>>>> >> >> that.
>> >>>>> >> >>
>> >>>>> >> >>
>> >>>>> >> >> On Mon, Apr 18, 2016 at 6:46 PM Steven Yi 
>> >>>>> >> >> wrote:
>> >>>>> >> >>>
>> >>>>> >> >>> Have you looked at the Git history? I haven't been following
>> >>>>> >> >>> that
>> >>>>> >> >>> closely
>> >>>>> >> >>> but the last build I did from yesterday had a problem where
>> >>>>> >> >>> the
>> >>>>> >> >>> Virtual
>> >>>>> >> >>> keyboard didn't send any midi values. I suspect it has to do
>> >>>>> >> >>> with
>> >>>>> >> >>> recent
>> >>>>> >> >>> lock changes, but I am just guessing. Besides these issues,
>> >>>>> >> >>> what
>> >>>>> >> >>> else
>> >>>>> >> >>> is
>> >>>>> >> >>> there?
>> >>>>> >> >>> On Mon, Apr 18, 2016 at 6:38 PM Rory Walsh 
>> >>>>> >> >>> wrote:
>> >>>>> >> >>>>
>> >>>>> >> >>>> Oeyvind and I have been trying to figure out what happened
>> >>>>> >> >>>> to the
>> >>>>> >> >>>> Windows
>> >>>>> >> >>>> build in mid-march which resulted in osc.dll requiring the
>> >>>>> >> >>>> lib-pthread .dll
>> >>>>> >> >>>> to be present in order to run. It was wasn't like this
>> >>>>> >> >>>> before
>> >>>>> >> >>>> then,
>> >>>>> >> >>>> but we
>> >>>>> >> >>>> can't tell what happened to change it. Anyone have any
>> >>>>> >> >>>> ideas? I
>> >>>>> >> >>>> can't
>> >>>>> >> >>>> use
>> >>>>> >> >>>> the canonical release of Csound lib to build Cabbage because
>> >>>>> >> >>>> of
>> >>>>> >> >>>> all
>> >>>>> >> >>>> the .dll
>> >>>>> >> >>>> dependencies, but I would love if we could still try to
>> >>>>> >> >>>> ensure as
>> >>>>> >> >>>> much of
>> >>>>> >> >>>> the plugin opcodes build statically as possible.
>> >>>>> >>
>> >>>>> >>
>> >>>>> >>
>> >>>>> >> --
>> >>>>> >>
>> >>>>> >> 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/
>> >>>>> >> http://soundcloud.com/t-emp
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>>
>> >>>>> 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/
>> >>>>> http://soundcloud.com/t-emp
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>>
>> >>> 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/
>> >>> http://soundcloud.com/t-emp
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> 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/
>> >> http://soundcloud.com/t-emp
>>
>>
>>
>> --
>>
>> 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/
>> http://soundcloud.com/t-emp
>

Just FYI, the issue about loading the libraries is only happening in
Windows command prompt.  In the msys2 shell, OSC opcodes and stkops
are loading fine.  OSC opcodes are working, and so is the virtual MIDI
(FLTK) keyboard.

On Tue, Apr 19, 2016 at 9:49 AM, Steven Yi  wrote:
> I'm looking at this now. Just FYI, my liblo build here has no winpthread:
>
> $ ldd liblo-7.dll
>         ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd2fe20000)
>         KERNEL32.DLL => /c/WINDOWS/system32/KERNEL32.DLL (0x7ffd2d9c0000)
>         KERNELBASE.dll => /c/WINDOWS/system32/KERNELBASE.dll (0x7ffd2cfd0000)
>         apphelp.dll => /c/WINDOWS/system32/apphelp.dll (0x7ffd2ac30000)
>         msvcrt.dll => /c/WINDOWS/system32/msvcrt.dll (0x7ffd2d6e0000)
>
> and neither does my osc.dll:
>
>
> $ ldd osc.dll
>         ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd2fe20000)
>         KERNEL32.DLL => /c/WINDOWS/system32/KERNEL32.DLL (0x7ffd2d9c0000)
>         KERNELBASE.dll => /c/WINDOWS/system32/KERNELBASE.dll (0x7ffd2cfd0000)
>         msvcrt.dll => /c/WINDOWS/system32/msvcrt.dll (0x7ffd2d6e0000)
>
> The liblo build is from January 14th. The osc.dll build is from April
> 11th. Then again, my build also doesn't even load the osc.dll opcode
> library:
>
>
> 'C:\Users\stevenyi\work\csound\csound\mingw64\csound-mingw64\stkops.dll'
> (-1)WARNING: could not open library
> 'C:\Users\stevenyi\work\csound\csound\mingw64\csound-mingw64\osc.dll'
> (-1)
>
> I am not sure what is going on now.
>
> On Tue, Apr 19, 2016 at 8:00 AM, Rory Walsh  wrote:
>> Exact same results here. I did look thought the git commit history, and the
>> only thing that really changed in the plugin CmakeLists.txt was the addition
>> of some extra "find modules" stuff:
>> https://github.com/csound/csound/commit/1d94318cf828e045c6c768889c55e467f1055d06
>> I think up to this point OSC.dll was still linking statically to pthread.
>> Oeyvind, have you tried using the CMakelists.txt file from the 7th of March
>> with the latest dev branch? Does it work?
>>
>> On 19 April 2016 at 12:35, Oeyvind Brandtsegg 
>> wrote:
>>>
>>> No I'm sure I did not.
>>> The build system and the msys2 installation has been used only to
>>> build Csound, set up for that purpose during January/February. I
>>> haven't built anything else. And only build the dependencies in
>>> packages by using pkgbuilds in the csound repo.
>>> Could it be related to another package that was added (to the Csound
>>> repo) sometime during March? I did build and install those.
>>>
>>>
>>> 2016-04-19 13:26 GMT+02:00 Michael Gogins :
>>> > Very strange. Perhaps you built it some other way.
>>> >
>>> > Best,
>>> > Mike
>>> >
>>> > -----------------------------------------------------
>>> > Michael Gogins
>>> > Irreducible Productions
>>> > http://michaelgogins.tumblr.com
>>> > Michael dot Gogins at gmail dot com
>>> >
>>> >
>>> > On Tue, Apr 19, 2016 at 6:51 AM, Oeyvind Brandtsegg
>>> >  wrote:
>>> >> ... I checked the history for liblo/PKGBUILD and it has not changed,
>>> >> so I guess the issue is rooted somewwhere else
>>> >>
>>> >> 2016-04-19 12:35 GMT+02:00 Oeyvind Brandtsegg
>>> >> :
>>> >>> you mean to build liblo?
>>> >>> Yes, maybe that is a thing to try.
>>> >>>
>>> >>> 2016-04-19 12:29 GMT+02:00 Michael Gogins :
>>> >>>> Thanks. Did you use the PKGBUILD script to build osc.dll? If so then
>>> >>>> we can
>>> >>>> just revert it.
>>> >>>>
>>> >>>> Best,
>>> >>>> Mike
>>> >>>>
>>> >>>> On Apr 19, 2016 6:00 AM, "Oeyvind Brandtsegg"
>>> >>>> 
>>> >>>> wrote:
>>> >>>>>
>>> >>>>> Here, the first one is my own build from March 7th, the second one
>>> >>>>> is
>>> >>>>> the Gogins rc2
>>> >>>>>
>>> >>>>> Administrator@HF-31335 MINGW64 /c/Program
>>> >>>>> Files/Csound6_x64_mymars/plugins64
>>> >>>>> $ ldd osc.dll
>>> >>>>>         ntdll.dll => /c/windows/SYSTEM32/ntdll.dll (0x773c0000)
>>> >>>>>         kernel32.dll => /c/windows/system32/kernel32.dll
>>> >>>>> (0x771a0000)
>>> >>>>>         KERNELBASE.dll => /c/windows/system32/KERNELBASE.dll
>>> >>>>> (0x7fefd210000)
>>> >>>>>         fshook64.dll => /c/program files
>>> >>>>> (x86)/f-secure/hips/fshook64.dll (0x737
>>> >>>>>     d0000)
>>> >>>>>         PSAPI.DLL => /c/windows/system32/PSAPI.DLL (0x77590000)
>>> >>>>>         ADVAPI32.dll => /c/windows/system32/ADVAPI32.dll
>>> >>>>> (0x7fefd6e0000)
>>> >>>>>         msvcrt.dll => /c/windows/system32/msvcrt.dll (0x7fefe0f0000)
>>> >>>>>         sechost.dll => /c/windows/SYSTEM32/sechost.dll
>>> >>>>> (0x7fefdbd0000)
>>> >>>>>         RPCRT4.dll => /c/windows/system32/RPCRT4.dll (0x7fefdfc0000)
>>> >>>>>         IPHLPAPI.DLL => /c/windows/system32/IPHLPAPI.DLL
>>> >>>>> (0x7fefa2c0000)
>>> >>>>>         NSI.dll => /c/windows/system32/NSI.dll (0x7fefd810000)
>>> >>>>>         WINNSI.DLL => /c/windows/system32/WINNSI.DLL (0x7fefa2a0000)
>>> >>>>>         USER32.dll => /c/windows/system32/USER32.dll (0x772c0000)
>>> >>>>>         GDI32.dll => /c/windows/system32/GDI32.dll (0x7fefe1e0000)
>>> >>>>>         LPK.dll => /c/windows/system32/LPK.dll (0x7fefe4e0000)
>>> >>>>>         USP10.dll => /c/windows/system32/USP10.dll (0x7fefe5d0000)
>>> >>>>>         WS2_32.dll => /c/windows/system32/WS2_32.dll (0x7fefd7c0000)
>>> >>>>>         WSOCK32.dll => /c/windows/system32/WSOCK32.dll
>>> >>>>> (0x7fef00b0000)
>>> >>>>>         IMM32.DLL => /c/windows/system32/IMM32.DLL (0x7fefe1b0000)
>>> >>>>>         MSCTF.dll => /c/windows/system32/MSCTF.dll (0x7fefe830000)
>>> >>>>>
>>> >>>>>
>>> >>>>> Administrator@HF-31335 MINGW64 /c/Program
>>> >>>>> Files/Csound6_x64/plugins64
>>> >>>>> $ ldd osc.dll
>>> >>>>>         ntdll.dll => /c/windows/SYSTEM32/ntdll.dll (0x773c0000)
>>> >>>>>         kernel32.dll => /c/windows/system32/kernel32.dll
>>> >>>>> (0x771a0000)
>>> >>>>>         KERNELBASE.dll => /c/windows/system32/KERNELBASE.dll
>>> >>>>> (0x7fefd210000)
>>> >>>>>         fshook64.dll => /c/program files
>>> >>>>> (x86)/f-secure/hips/fshook64.dll (0x737d0000)
>>> >>>>>         PSAPI.DLL => /c/windows/system32/PSAPI.DLL (0x77590000)
>>> >>>>>         ADVAPI32.dll => /c/windows/system32/ADVAPI32.dll
>>> >>>>> (0x7fefd6e0000)
>>> >>>>>         msvcrt.dll => /c/windows/system32/msvcrt.dll (0x7fefe0f0000)
>>> >>>>>         sechost.dll => /c/windows/SYSTEM32/sechost.dll
>>> >>>>> (0x7fefdbd0000)
>>> >>>>>         RPCRT4.dll => /c/windows/system32/RPCRT4.dll (0x7fefdfc0000)
>>> >>>>>         IPHLPAPI.DLL => /c/windows/system32/IPHLPAPI.DLL
>>> >>>>> (0x7fefa2c0000)
>>> >>>>>         NSI.dll => /c/windows/system32/NSI.dll (0x7fefd810000)
>>> >>>>>         WINNSI.DLL => /c/windows/system32/WINNSI.DLL (0x7fefa2a0000)
>>> >>>>>         libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll
>>> >>>>> (0x64940000)
>>> >>>>>         USER32.dll => /c/windows/system32/USER32.dll (0x772c0000)
>>> >>>>>         GDI32.dll => /c/windows/system32/GDI32.dll (0x7fefe1e0000)
>>> >>>>>         LPK.dll => /c/windows/system32/LPK.dll (0x7fefe4e0000)
>>> >>>>>         USP10.dll => /c/windows/system32/USP10.dll (0x7fefe5d0000)
>>> >>>>>         WS2_32.dll => /c/windows/system32/WS2_32.dll (0x7fefd7c0000)
>>> >>>>>         WSOCK32.dll => /c/windows/system32/WSOCK32.dll
>>> >>>>> (0x7fef00b0000)
>>> >>>>>         IMM32.DLL => /c/windows/system32/IMM32.DLL (0x7fefe1b0000)
>>> >>>>>         MSCTF.dll => /c/windows/system32/MSCTF.dll (0x7fefe830000)
>>> >>>>>
>>> >>>>>
>>> >>>>> 2016-04-19 11:39 GMT+02:00 Michael Gogins
>>> >>>>> :
>>> >>>>> > What are the results of running ldd on both versions of osc.dll?
>>> >>>>> >
>>> >>>>> > Regards,
>>> >>>>> > Mike
>>> >>>>> >
>>> >>>>> > On Apr 19, 2016 2:57 AM, "Oeyvind Brandtsegg"
>>> >>>>> > 
>>> >>>>> > wrote:
>>> >>>>> >>
>>> >>>>> >> I don't know the fine details about the technicalities of this,
>>> >>>>> >> but I
>>> >>>>> >> can confirm that osc.dll was built and working in the Csound
>>> >>>>> >> version I
>>> >>>>> >> built March 7th. I tested this again just now. Open Sound Control
>>> >>>>> >> also
>>> >>>>> >> confirmed working in this version. To me, this seems like a
>>> >>>>> >> strong
>>> >>>>> >> indicator that it is indeed possible to build osc.dll without
>>> >>>>> >> getting
>>> >>>>> >> the libpthread dependency. This version does not complain about
>>> >>>>> >> any
>>> >>>>> >> missing dlls, whereas the more recent ones show an error dialog
>>> >>>>> >> at
>>> >>>>> >> startup (unless the dlls are distributed in the csound/bin
>>> >>>>> >> folder).
>>> >>>>> >> I think it is *very* important we get this sorted out, as it will
>>> >>>>> >> mean
>>> >>>>> >> the different frontends and other ways of acessing Csound will
>>> >>>>> >> otherwise interfere in unpredictable ways,
>>> >>>>> >>
>>> >>>>> >>
>>> >>>>> >> 2016-04-19 2:27 GMT+02:00 Michael Gogins
>>> >>>>> >> :
>>> >>>>> >> > LIblo requires pthreads. And that is in fact the source of this
>>> >>>>> >> > dependency as far as I can tell. I think the build recipe for
>>> >>>>> >> > liblo
>>> >>>>> >> > could be changed to use a static version of pthreads, however.
>>> >>>>> >> >
>>> >>>>> >> > By the way, I am not sure the static build idea is required for
>>> >>>>> >> > Csound. I was able to run CsoundVST about a year ago with
>>> >>>>> >> > Reaper in
>>> >>>>> >> > spite of DLL conflicts by ensuring that all DLLs required by
>>> >>>>> >> > Csound
>>> >>>>> >> > were in the VST bin directory.
>>> >>>>> >> >
>>> >>>>> >> > There also now appears to be a new crash in CsoundQt realted to
>>> >>>>> >> > the
>>> >>>>> >> > Csound MIDI module.
>>> >>>>> >> >
>>> >>>>> >> > The other issue I am looking at is a problem with line endings
>>> >>>>> >> > in
>>> >>>>> >> > CsoundQt. No matter what the number of line endings for each
>>> >>>>> >> > line
>>> >>>>> >> > keeps increasing, and it's impossible to turn off the Windows
>>> >>>>> >> > line
>>> >>>>> >> > endings. I think I should be able to fix this one though.
>>> >>>>> >> >
>>> >>>>> >> > Best,
>>> >>>>> >> > Mike
>>> >>>>> >> >
>>> >>>>> >> >
>>> >>>>> >> >
>>> >>>>> >> >
>>> >>>>> >> >
>>> >>>>> >> > -----------------------------------------------------
>>> >>>>> >> > Michael Gogins
>>> >>>>> >> > Irreducible Productions
>>> >>>>> >> > http://michaelgogins.tumblr.com
>>> >>>>> >> > Michael dot Gogins at gmail dot com
>>> >>>>> >> >
>>> >>>>> >> >
>>> >>>>> >> > On Mon, Apr 18, 2016 at 6:53 PM, Steven Yi 
>>> >>>>> >> > wrote:
>>> >>>>> >> >> Btw: we used to have separate thread implementations. We
>>> >>>>> >> >> switched to
>>> >>>>> >> >> pthreads, but perhaps this was a mistake and we should have
>>> >>>>> >> >> kept the
>>> >>>>> >> >> implementations but reduced it down to just pthreads, win32,
>>> >>>>> >> >> and
>>> >>>>> >> >> no-op.
>>> >>>>> >> >> If
>>> >>>>> >> >> liblo requires pthreads though, not much to do there about
>>> >>>>> >> >> that.
>>> >>>>> >> >>
>>> >>>>> >> >>
>>> >>>>> >> >> On Mon, Apr 18, 2016 at 6:46 PM Steven Yi 
>>> >>>>> >> >> wrote:
>>> >>>>> >> >>>
>>> >>>>> >> >>> Have you looked at the Git history? I haven't been following
>>> >>>>> >> >>> that
>>> >>>>> >> >>> closely
>>> >>>>> >> >>> but the last build I did from yesterday had a problem where
>>> >>>>> >> >>> the
>>> >>>>> >> >>> Virtual
>>> >>>>> >> >>> keyboard didn't send any midi values. I suspect it has to do
>>> >>>>> >> >>> with
>>> >>>>> >> >>> recent
>>> >>>>> >> >>> lock changes, but I am just guessing. Besides these issues,
>>> >>>>> >> >>> what
>>> >>>>> >> >>> else
>>> >>>>> >> >>> is
>>> >>>>> >> >>> there?
>>> >>>>> >> >>> On Mon, Apr 18, 2016 at 6:38 PM Rory Walsh 
>>> >>>>> >> >>> wrote:
>>> >>>>> >> >>>>
>>> >>>>> >> >>>> Oeyvind and I have been trying to figure out what happened
>>> >>>>> >> >>>> to the
>>> >>>>> >> >>>> Windows
>>> >>>>> >> >>>> build in mid-march which resulted in osc.dll requiring the
>>> >>>>> >> >>>> lib-pthread .dll
>>> >>>>> >> >>>> to be present in order to run. It was wasn't like this
>>> >>>>> >> >>>> before
>>> >>>>> >> >>>> then,
>>> >>>>> >> >>>> but we
>>> >>>>> >> >>>> can't tell what happened to change it. Anyone have any
>>> >>>>> >> >>>> ideas? I
>>> >>>>> >> >>>> can't
>>> >>>>> >> >>>> use
>>> >>>>> >> >>>> the canonical release of Csound lib to build Cabbage because
>>> >>>>> >> >>>> of
>>> >>>>> >> >>>> all
>>> >>>>> >> >>>> the .dll
>>> >>>>> >> >>>> dependencies, but I would love if we could still try to
>>> >>>>> >> >>>> ensure as
>>> >>>>> >> >>>> much of
>>> >>>>> >> >>>> the plugin opcodes build statically as possible.
>>> >>>>> >>
>>> >>>>> >>
>>> >>>>> >>
>>> >>>>> >> --
>>> >>>>> >>
>>> >>>>> >> 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/
>>> >>>>> >> http://soundcloud.com/t-emp
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> --
>>> >>>>>
>>> >>>>> 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/
>>> >>>>> http://soundcloud.com/t-emp
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>>
>>> >>> 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/
>>> >>> http://soundcloud.com/t-emp
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >>
>>> >> 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/
>>> >> http://soundcloud.com/t-emp
>>>
>>>
>>>
>>> --
>>>
>>> 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/
>>> http://soundcloud.com/t-emp
>>

I do see the dependency for osc.dll on libwinpthread-1.dll when using
dependency walker. Oddly, not for csound64.dll. I tried removing
pthread as well as replacing with ${PTHREAD_LIBRARY} in
Opcodes/CMakeLists.txt and to no avail, the dependency still shows up.

I'm confused why libwinpthread-1.dll isn't showing up as a dependency
for libcsound.

On Tue, Apr 19, 2016 at 11:16 AM, Rory Walsh  wrote:
> I just updated from the current tip, rebuilt everything and ran ldd, it
> shows no mention of libpthread. But when I run Cabbage on another machine, I
> get the pthread error unless I remove or rename osc.dll?
>
> On 19 April 2016 at 15:14, Steven Yi  wrote:
>>
>> Just FYI, the issue about loading the libraries is only happening in
>> Windows command prompt.  In the msys2 shell, OSC opcodes and stkops
>> are loading fine.  OSC opcodes are working, and so is the virtual MIDI
>> (FLTK) keyboard.
>>
>> On Tue, Apr 19, 2016 at 9:49 AM, Steven Yi  wrote:
>> > I'm looking at this now. Just FYI, my liblo build here has no
>> > winpthread:
>> >
>> > $ ldd liblo-7.dll
>> >         ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd2fe20000)
>> >         KERNEL32.DLL => /c/WINDOWS/system32/KERNEL32.DLL
>> > (0x7ffd2d9c0000)
>> >         KERNELBASE.dll => /c/WINDOWS/system32/KERNELBASE.dll
>> > (0x7ffd2cfd0000)
>> >         apphelp.dll => /c/WINDOWS/system32/apphelp.dll (0x7ffd2ac30000)
>> >         msvcrt.dll => /c/WINDOWS/system32/msvcrt.dll (0x7ffd2d6e0000)
>> >
>> > and neither does my osc.dll:
>> >
>> >
>> > $ ldd osc.dll
>> >         ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd2fe20000)
>> >         KERNEL32.DLL => /c/WINDOWS/system32/KERNEL32.DLL
>> > (0x7ffd2d9c0000)
>> >         KERNELBASE.dll => /c/WINDOWS/system32/KERNELBASE.dll
>> > (0x7ffd2cfd0000)
>> >         msvcrt.dll => /c/WINDOWS/system32/msvcrt.dll (0x7ffd2d6e0000)
>> >
>> > The liblo build is from January 14th. The osc.dll build is from April
>> > 11th. Then again, my build also doesn't even load the osc.dll opcode
>> > library:
>> >
>> >
>> > 'C:\Users\stevenyi\work\csound\csound\mingw64\csound-mingw64\stkops.dll'
>> > (-1)WARNING: could not open library
>> > 'C:\Users\stevenyi\work\csound\csound\mingw64\csound-mingw64\osc.dll'
>> > (-1)
>> >
>> > I am not sure what is going on now.
>> >
>> > On Tue, Apr 19, 2016 at 8:00 AM, Rory Walsh  wrote:
>> >> Exact same results here. I did look thought the git commit history, and
>> >> the
>> >> only thing that really changed in the plugin CmakeLists.txt was the
>> >> addition
>> >> of some extra "find modules" stuff:
>> >>
>> >> https://github.com/csound/csound/commit/1d94318cf828e045c6c768889c55e467f1055d06
>> >> I think up to this point OSC.dll was still linking statically to
>> >> pthread.
>> >> Oeyvind, have you tried using the CMakelists.txt file from the 7th of
>> >> March
>> >> with the latest dev branch? Does it work?
>> >>
>> >> On 19 April 2016 at 12:35, Oeyvind Brandtsegg
>> >> 
>> >> wrote:
>> >>>
>> >>> No I'm sure I did not.
>> >>> The build system and the msys2 installation has been used only to
>> >>> build Csound, set up for that purpose during January/February. I
>> >>> haven't built anything else. And only build the dependencies in
>> >>> packages by using pkgbuilds in the csound repo.
>> >>> Could it be related to another package that was added (to the Csound
>> >>> repo) sometime during March? I did build and install those.
>> >>>
>> >>>
>> >>> 2016-04-19 13:26 GMT+02:00 Michael Gogins :
>> >>> > Very strange. Perhaps you built it some other way.
>> >>> >
>> >>> > Best,
>> >>> > Mike
>> >>> >
>> >>> > -----------------------------------------------------
>> >>> > Michael Gogins
>> >>> > Irreducible Productions
>> >>> > http://michaelgogins.tumblr.com
>> >>> > Michael dot Gogins at gmail dot com
>> >>> >
>> >>> >
>> >>> > On Tue, Apr 19, 2016 at 6:51 AM, Oeyvind Brandtsegg
>> >>> >  wrote:
>> >>> >> ... I checked the history for liblo/PKGBUILD and it has not
>> >>> >> changed,
>> >>> >> so I guess the issue is rooted somewwhere else
>> >>> >>
>> >>> >> 2016-04-19 12:35 GMT+02:00 Oeyvind Brandtsegg
>> >>> >> :
>> >>> >>> you mean to build liblo?
>> >>> >>> Yes, maybe that is a thing to try.
>> >>> >>>
>> >>> >>> 2016-04-19 12:29 GMT+02:00 Michael Gogins
>> >>> >>> :
>> >>> >>>> Thanks. Did you use the PKGBUILD script to build osc.dll? If so
>> >>> >>>> then
>> >>> >>>> we can
>> >>> >>>> just revert it.
>> >>> >>>>
>> >>> >>>> Best,
>> >>> >>>> Mike
>> >>> >>>>
>> >>> >>>> On Apr 19, 2016 6:00 AM, "Oeyvind Brandtsegg"
>> >>> >>>> 
>> >>> >>>> wrote:
>> >>> >>>>>
>> >>> >>>>> Here, the first one is my own build from March 7th, the second
>> >>> >>>>> one
>> >>> >>>>> is
>> >>> >>>>> the Gogins rc2
>> >>> >>>>>
>> >>> >>>>> Administrator@HF-31335 MINGW64 /c/Program
>> >>> >>>>> Files/Csound6_x64_mymars/plugins64
>> >>> >>>>> $ ldd osc.dll
>> >>> >>>>>         ntdll.dll => /c/windows/SYSTEM32/ntdll.dll (0x773c0000)
>> >>> >>>>>         kernel32.dll => /c/windows/system32/kernel32.dll
>> >>> >>>>> (0x771a0000)
>> >>> >>>>>         KERNELBASE.dll => /c/windows/system32/KERNELBASE.dll
>> >>> >>>>> (0x7fefd210000)
>> >>> >>>>>         fshook64.dll => /c/program files
>> >>> >>>>> (x86)/f-secure/hips/fshook64.dll (0x737
>> >>> >>>>>     d0000)
>> >>> >>>>>         PSAPI.DLL => /c/windows/system32/PSAPI.DLL (0x77590000)
>> >>> >>>>>         ADVAPI32.dll => /c/windows/system32/ADVAPI32.dll
>> >>> >>>>> (0x7fefd6e0000)
>> >>> >>>>>         msvcrt.dll => /c/windows/system32/msvcrt.dll
>> >>> >>>>> (0x7fefe0f0000)
>> >>> >>>>>         sechost.dll => /c/windows/SYSTEM32/sechost.dll
>> >>> >>>>> (0x7fefdbd0000)
>> >>> >>>>>         RPCRT4.dll => /c/windows/system32/RPCRT4.dll
>> >>> >>>>> (0x7fefdfc0000)
>> >>> >>>>>         IPHLPAPI.DLL => /c/windows/system32/IPHLPAPI.DLL
>> >>> >>>>> (0x7fefa2c0000)
>> >>> >>>>>         NSI.dll => /c/windows/system32/NSI.dll (0x7fefd810000)
>> >>> >>>>>         WINNSI.DLL => /c/windows/system32/WINNSI.DLL
>> >>> >>>>> (0x7fefa2a0000)
>> >>> >>>>>         USER32.dll => /c/windows/system32/USER32.dll
>> >>> >>>>> (0x772c0000)
>> >>> >>>>>         GDI32.dll => /c/windows/system32/GDI32.dll
>> >>> >>>>> (0x7fefe1e0000)
>> >>> >>>>>         LPK.dll => /c/windows/system32/LPK.dll (0x7fefe4e0000)
>> >>> >>>>>         USP10.dll => /c/windows/system32/USP10.dll
>> >>> >>>>> (0x7fefe5d0000)
>> >>> >>>>>         WS2_32.dll => /c/windows/system32/WS2_32.dll
>> >>> >>>>> (0x7fefd7c0000)
>> >>> >>>>>         WSOCK32.dll => /c/windows/system32/WSOCK32.dll
>> >>> >>>>> (0x7fef00b0000)
>> >>> >>>>>         IMM32.DLL => /c/windows/system32/IMM32.DLL
>> >>> >>>>> (0x7fefe1b0000)
>> >>> >>>>>         MSCTF.dll => /c/windows/system32/MSCTF.dll
>> >>> >>>>> (0x7fefe830000)
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> Administrator@HF-31335 MINGW64 /c/Program
>> >>> >>>>> Files/Csound6_x64/plugins64
>> >>> >>>>> $ ldd osc.dll
>> >>> >>>>>         ntdll.dll => /c/windows/SYSTEM32/ntdll.dll (0x773c0000)
>> >>> >>>>>         kernel32.dll => /c/windows/system32/kernel32.dll
>> >>> >>>>> (0x771a0000)
>> >>> >>>>>         KERNELBASE.dll => /c/windows/system32/KERNELBASE.dll
>> >>> >>>>> (0x7fefd210000)
>> >>> >>>>>         fshook64.dll => /c/program files
>> >>> >>>>> (x86)/f-secure/hips/fshook64.dll (0x737d0000)
>> >>> >>>>>         PSAPI.DLL => /c/windows/system32/PSAPI.DLL (0x77590000)
>> >>> >>>>>         ADVAPI32.dll => /c/windows/system32/ADVAPI32.dll
>> >>> >>>>> (0x7fefd6e0000)
>> >>> >>>>>         msvcrt.dll => /c/windows/system32/msvcrt.dll
>> >>> >>>>> (0x7fefe0f0000)
>> >>> >>>>>         sechost.dll => /c/windows/SYSTEM32/sechost.dll
>> >>> >>>>> (0x7fefdbd0000)
>> >>> >>>>>         RPCRT4.dll => /c/windows/system32/RPCRT4.dll
>> >>> >>>>> (0x7fefdfc0000)
>> >>> >>>>>         IPHLPAPI.DLL => /c/windows/system32/IPHLPAPI.DLL
>> >>> >>>>> (0x7fefa2c0000)
>> >>> >>>>>         NSI.dll => /c/windows/system32/NSI.dll (0x7fefd810000)
>> >>> >>>>>         WINNSI.DLL => /c/windows/system32/WINNSI.DLL
>> >>> >>>>> (0x7fefa2a0000)
>> >>> >>>>>         libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll
>> >>> >>>>> (0x64940000)
>> >>> >>>>>         USER32.dll => /c/windows/system32/USER32.dll
>> >>> >>>>> (0x772c0000)
>> >>> >>>>>         GDI32.dll => /c/windows/system32/GDI32.dll
>> >>> >>>>> (0x7fefe1e0000)
>> >>> >>>>>         LPK.dll => /c/windows/system32/LPK.dll (0x7fefe4e0000)
>> >>> >>>>>         USP10.dll => /c/windows/system32/USP10.dll
>> >>> >>>>> (0x7fefe5d0000)
>> >>> >>>>>         WS2_32.dll => /c/windows/system32/WS2_32.dll
>> >>> >>>>> (0x7fefd7c0000)
>> >>> >>>>>         WSOCK32.dll => /c/windows/system32/WSOCK32.dll
>> >>> >>>>> (0x7fef00b0000)
>> >>> >>>>>         IMM32.DLL => /c/windows/system32/IMM32.DLL
>> >>> >>>>> (0x7fefe1b0000)
>> >>> >>>>>         MSCTF.dll => /c/windows/system32/MSCTF.dll
>> >>> >>>>> (0x7fefe830000)
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> 2016-04-19 11:39 GMT+02:00 Michael Gogins
>> >>> >>>>> :
>> >>> >>>>> > What are the results of running ldd on both versions of
>> >>> >>>>> > osc.dll?
>> >>> >>>>> >
>> >>> >>>>> > Regards,
>> >>> >>>>> > Mike
>> >>> >>>>> >
>> >>> >>>>> > On Apr 19, 2016 2:57 AM, "Oeyvind Brandtsegg"
>> >>> >>>>> > 
>> >>> >>>>> > wrote:
>> >>> >>>>> >>
>> >>> >>>>> >> I don't know the fine details about the technicalities of
>> >>> >>>>> >> this,
>> >>> >>>>> >> but I
>> >>> >>>>> >> can confirm that osc.dll was built and working in the Csound
>> >>> >>>>> >> version I
>> >>> >>>>> >> built March 7th. I tested this again just now. Open Sound
>> >>> >>>>> >> Control
>> >>> >>>>> >> also
>> >>> >>>>> >> confirmed working in this version. To me, this seems like a
>> >>> >>>>> >> strong
>> >>> >>>>> >> indicator that it is indeed possible to build osc.dll without
>> >>> >>>>> >> getting
>> >>> >>>>> >> the libpthread dependency. This version does not complain
>> >>> >>>>> >> about
>> >>> >>>>> >> any
>> >>> >>>>> >> missing dlls, whereas the more recent ones show an error
>> >>> >>>>> >> dialog
>> >>> >>>>> >> at
>> >>> >>>>> >> startup (unless the dlls are distributed in the csound/bin
>> >>> >>>>> >> folder).
>> >>> >>>>> >> I think it is *very* important we get this sorted out, as it
>> >>> >>>>> >> will
>> >>> >>>>> >> mean
>> >>> >>>>> >> the different frontends and other ways of acessing Csound
>> >>> >>>>> >> will
>> >>> >>>>> >> otherwise interfere in unpredictable ways,
>> >>> >>>>> >>
>> >>> >>>>> >>
>> >>> >>>>> >> 2016-04-19 2:27 GMT+02:00 Michael Gogins
>> >>> >>>>> >> :
>> >>> >>>>> >> > LIblo requires pthreads. And that is in fact the source of
>> >>> >>>>> >> > this
>> >>> >>>>> >> > dependency as far as I can tell. I think the build recipe
>> >>> >>>>> >> > for
>> >>> >>>>> >> > liblo
>> >>> >>>>> >> > could be changed to use a static version of pthreads,
>> >>> >>>>> >> > however.
>> >>> >>>>> >> >
>> >>> >>>>> >> > By the way, I am not sure the static build idea is required
>> >>> >>>>> >> > for
>> >>> >>>>> >> > Csound. I was able to run CsoundVST about a year ago with
>> >>> >>>>> >> > Reaper in
>> >>> >>>>> >> > spite of DLL conflicts by ensuring that all DLLs required
>> >>> >>>>> >> > by
>> >>> >>>>> >> > Csound
>> >>> >>>>> >> > were in the VST bin directory.
>> >>> >>>>> >> >
>> >>> >>>>> >> > There also now appears to be a new crash in CsoundQt
>> >>> >>>>> >> > realted to
>> >>> >>>>> >> > the
>> >>> >>>>> >> > Csound MIDI module.
>> >>> >>>>> >> >
>> >>> >>>>> >> > The other issue I am looking at is a problem with line
>> >>> >>>>> >> > endings
>> >>> >>>>> >> > in
>> >>> >>>>> >> > CsoundQt. No matter what the number of line endings for
>> >>> >>>>> >> > each
>> >>> >>>>> >> > line
>> >>> >>>>> >> > keeps increasing, and it's impossible to turn off the
>> >>> >>>>> >> > Windows
>> >>> >>>>> >> > line
>> >>> >>>>> >> > endings. I think I should be able to fix this one though.
>> >>> >>>>> >> >
>> >>> >>>>> >> > Best,
>> >>> >>>>> >> > Mike
>> >>> >>>>> >> >
>> >>> >>>>> >> >
>> >>> >>>>> >> >
>> >>> >>>>> >> >
>> >>> >>>>> >> >
>> >>> >>>>> >> > -----------------------------------------------------
>> >>> >>>>> >> > Michael Gogins
>> >>> >>>>> >> > Irreducible Productions
>> >>> >>>>> >> > http://michaelgogins.tumblr.com
>> >>> >>>>> >> > Michael dot Gogins at gmail dot com
>> >>> >>>>> >> >
>> >>> >>>>> >> >
>> >>> >>>>> >> > On Mon, Apr 18, 2016 at 6:53 PM, Steven Yi
>> >>> >>>>> >> > 
>> >>> >>>>> >> > wrote:
>> >>> >>>>> >> >> Btw: we used to have separate thread implementations. We
>> >>> >>>>> >> >> switched to
>> >>> >>>>> >> >> pthreads, but perhaps this was a mistake and we should
>> >>> >>>>> >> >> have
>> >>> >>>>> >> >> kept the
>> >>> >>>>> >> >> implementations but reduced it down to just pthreads,
>> >>> >>>>> >> >> win32,
>> >>> >>>>> >> >> and
>> >>> >>>>> >> >> no-op.
>> >>> >>>>> >> >> If
>> >>> >>>>> >> >> liblo requires pthreads though, not much to do there about
>> >>> >>>>> >> >> that.
>> >>> >>>>> >> >>
>> >>> >>>>> >> >>
>> >>> >>>>> >> >> On Mon, Apr 18, 2016 at 6:46 PM Steven Yi
>> >>> >>>>> >> >> 
>> >>> >>>>> >> >> wrote:
>> >>> >>>>> >> >>>
>> >>> >>>>> >> >>> Have you looked at the Git history? I haven't been
>> >>> >>>>> >> >>> following
>> >>> >>>>> >> >>> that
>> >>> >>>>> >> >>> closely
>> >>> >>>>> >> >>> but the last build I did from yesterday had a problem
>> >>> >>>>> >> >>> where
>> >>> >>>>> >> >>> the
>> >>> >>>>> >> >>> Virtual
>> >>> >>>>> >> >>> keyboard didn't send any midi values. I suspect it has to
>> >>> >>>>> >> >>> do
>> >>> >>>>> >> >>> with
>> >>> >>>>> >> >>> recent
>> >>> >>>>> >> >>> lock changes, but I am just guessing. Besides these
>> >>> >>>>> >> >>> issues,
>> >>> >>>>> >> >>> what
>> >>> >>>>> >> >>> else
>> >>> >>>>> >> >>> is
>> >>> >>>>> >> >>> there?
>> >>> >>>>> >> >>> On Mon, Apr 18, 2016 at 6:38 PM Rory Walsh
>> >>> >>>>> >> >>> 
>> >>> >>>>> >> >>> wrote:
>> >>> >>>>> >> >>>>
>> >>> >>>>> >> >>>> Oeyvind and I have been trying to figure out what
>> >>> >>>>> >> >>>> happened
>> >>> >>>>> >> >>>> to the
>> >>> >>>>> >> >>>> Windows
>> >>> >>>>> >> >>>> build in mid-march which resulted in osc.dll requiring
>> >>> >>>>> >> >>>> the
>> >>> >>>>> >> >>>> lib-pthread .dll
>> >>> >>>>> >> >>>> to be present in order to run. It was wasn't like this
>> >>> >>>>> >> >>>> before
>> >>> >>>>> >> >>>> then,
>> >>> >>>>> >> >>>> but we
>> >>> >>>>> >> >>>> can't tell what happened to change it. Anyone have any
>> >>> >>>>> >> >>>> ideas? I
>> >>> >>>>> >> >>>> can't
>> >>> >>>>> >> >>>> use
>> >>> >>>>> >> >>>> the canonical release of Csound lib to build Cabbage
>> >>> >>>>> >> >>>> because
>> >>> >>>>> >> >>>> of
>> >>> >>>>> >> >>>> all
>> >>> >>>>> >> >>>> the .dll
>> >>> >>>>> >> >>>> dependencies, but I would love if we could still try to
>> >>> >>>>> >> >>>> ensure as
>> >>> >>>>> >> >>>> much of
>> >>> >>>>> >> >>>> the plugin opcodes build statically as possible.
>> >>> >>>>> >>
>> >>> >>>>> >>
>> >>> >>>>> >>
>> >>> >>>>> >> --
>> >>> >>>>> >>
>> >>> >>>>> >> 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/
>> >>> >>>>> >> http://soundcloud.com/t-emp
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> --
>> >>> >>>>>
>> >>> >>>>> 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/
>> >>> >>>>> http://soundcloud.com/t-emp
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> --
>> >>> >>>
>> >>> >>> 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/
>> >>> >>> http://soundcloud.com/t-emp
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> --
>> >>> >>
>> >>> >> 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/
>> >>> >> http://soundcloud.com/t-emp
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>>
>> >>> 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/
>> >>> http://soundcloud.com/t-emp
>> >>
>> >>
>

Csound links pthreads statically. For some reason not quite identified, osc.dll links pthreads dynamically. It's probably just lacking the correct linker options.

Best,
Mike

The thing is, I haven't found a static pthread library on my system as of yet. Maybe I'm missing something though, as it doesn't make sense other than what you mention.

I installed winpthreads. Mingw64 has its own libpthread which is what Csound links to. I think. I will tell my details later, on the bus to our farm after returning from Israel Sunday.

Best, Mike

No. You can link directly but that is not statically.

Best,
Mike

This is the compiler command from my build:

cd /D/msys64/home/restore/csound/mingw64/csound-mingw64/Opcodes &&
/D/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 -lpthread
-lwsock32 -lws2_32 -liphlpapi -lkernel32 -luser32 -lgdi32 -lwinspool
-lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32

Note that liblo is linked statically but the other libraries after it
are linked dynamically. This is almost certainly the problem. I am
trying to figure out how to fix this.

Best,
Mike

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


On Tue, Apr 19, 2016 at 2:20 PM, Rory Walsh  wrote:
> I'm pretty sure that Ive used --static along with libpthread.dll in the past
> to statically build some of my apps. At least it got rid of the need for me
> to bundle pthread with my exe. Note that I was only able to do this with the
> pthread dll that shipped with the last version of mingw that I was using,
> pre msys2. I was never able to do it with the pthread I installed myself.
>
> On 19 April 2016 at 18:19, Michael Gogins  wrote:
>>
>> No. You can link directly but that is not statically.
>>
>> Best,
>> Mike
>>
>> On Apr 19, 2016 1:14 PM, "Rory Walsh"  wrote:
>>>
>>> You can link statically against the .dll as far as I remember?
>>>
>>> On 19 April 2016 at 18:13, Rory Walsh  wrote:
>>>>
>>>> I tried removing the --enable-shared in this file:
>>>>
>>>> https://github.com/csound/csound/blob/develop/mingw64/packages/liblo/PKGBUILD#L20
>>>> But that didn't seem to work for me. I wouldn't mind someone else trying
>>>> it, just in case I botched it up ;)
>>>>
>>>> On 19 April 2016 at 17:35, Michael Gogins 
>>>> wrote:
>>>>>
>>>>> Csound links pthreads statically. For some reason not quite identified,
>>>>> osc.dll links pthreads dynamically. It's probably just lacking the correct
>>>>> linker options.
>>>>>
>>>>> Best,
>>>>> Mike
>>>>>
>>>>> On Apr 19, 2016 12:26 PM, "Steven Yi"  wrote:
>>>>>>
>>>>>> I do see the dependency for osc.dll on libwinpthread-1.dll when using
>>>>>> dependency walker. Oddly, not for csound64.dll. I tried removing
>>>>>> pthread as well as replacing with ${PTHREAD_LIBRARY} in
>>>>>> Opcodes/CMakeLists.txt and to no avail, the dependency still shows up.
>>>>>>
>>>>>> I'm confused why libwinpthread-1.dll isn't showing up as a dependency
>>>>>> for libcsound.
>>>>>>
>>>>>> On Tue, Apr 19, 2016 at 11:16 AM, Rory Walsh  wrote:
>>>>>> > I just updated from the current tip, rebuilt everything and ran ldd,
>>>>>> > it
>>>>>> > shows no mention of libpthread. But when I run Cabbage on another
>>>>>> > machine, I
>>>>>> > get the pthread error unless I remove or rename osc.dll?
>>>>>> >
>>>>>> > On 19 April 2016 at 15:14, Steven Yi  wrote:
>>>>>> >>
>>>>>> >> Just FYI, the issue about loading the libraries is only happening
>>>>>> >> in
>>>>>> >> Windows command prompt.  In the msys2 shell, OSC opcodes and stkops
>>>>>> >> are loading fine.  OSC opcodes are working, and so is the virtual
>>>>>> >> MIDI
>>>>>> >> (FLTK) keyboard.
>>>>>> >>
>>>>>> >> On Tue, Apr 19, 2016 at 9:49 AM, Steven Yi 
>>>>>> >> wrote:
>>>>>> >> > I'm looking at this now. Just FYI, my liblo build here has no
>>>>>> >> > winpthread:
>>>>>> >> >
>>>>>> >> > $ ldd liblo-7.dll
>>>>>> >> >         ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll
>>>>>> >> > (0x7ffd2fe20000)
>>>>>> >> >         KERNEL32.DLL => /c/WINDOWS/system32/KERNEL32.DLL
>>>>>> >> > (0x7ffd2d9c0000)
>>>>>> >> >         KERNELBASE.dll => /c/WINDOWS/system32/KERNELBASE.dll
>>>>>> >> > (0x7ffd2cfd0000)
>>>>>> >> >         apphelp.dll => /c/WINDOWS/system32/apphelp.dll
>>>>>> >> > (0x7ffd2ac30000)
>>>>>> >> >         msvcrt.dll => /c/WINDOWS/system32/msvcrt.dll
>>>>>> >> > (0x7ffd2d6e0000)
>>>>>> >> >
>>>>>> >> > and neither does my osc.dll:
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > $ ldd osc.dll
>>>>>> >> >         ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll
>>>>>> >> > (0x7ffd2fe20000)
>>>>>> >> >         KERNEL32.DLL => /c/WINDOWS/system32/KERNEL32.DLL
>>>>>> >> > (0x7ffd2d9c0000)
>>>>>> >> >         KERNELBASE.dll => /c/WINDOWS/system32/KERNELBASE.dll
>>>>>> >> > (0x7ffd2cfd0000)
>>>>>> >> >         msvcrt.dll => /c/WINDOWS/system32/msvcrt.dll
>>>>>> >> > (0x7ffd2d6e0000)
>>>>>> >> >
>>>>>> >> > The liblo build is from January 14th. The osc.dll build is from
>>>>>> >> > April
>>>>>> >> > 11th. Then again, my build also doesn't even load the osc.dll
>>>>>> >> > opcode
>>>>>> >> > library:
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > 'C:\Users\stevenyi\work\csound\csound\mingw64\csound-mingw64\stkops.dll'
>>>>>> >> > (-1)WARNING: could not open library
>>>>>> >> >
>>>>>> >> > 'C:\Users\stevenyi\work\csound\csound\mingw64\csound-mingw64\osc.dll'
>>>>>> >> > (-1)
>>>>>> >> >
>>>>>> >> > I am not sure what is going on now.
>>>>>> >> >
>>>>>> >> > On Tue, Apr 19, 2016 at 8:00 AM, Rory Walsh 
>>>>>> >> > wrote:
>>>>>> >> >> Exact same results here. I did look thought the git commit
>>>>>> >> >> history, and
>>>>>> >> >> the
>>>>>> >> >> only thing that really changed in the plugin CmakeLists.txt was
>>>>>> >> >> the
>>>>>> >> >> addition
>>>>>> >> >> of some extra "find modules" stuff:
>>>>>> >> >>
>>>>>> >> >>
>>>>>> >> >> https://github.com/csound/csound/commit/1d94318cf828e045c6c768889c55e467f1055d06
>>>>>> >> >> I think up to this point OSC.dll was still linking statically to
>>>>>> >> >> pthread.
>>>>>> >> >> Oeyvind, have you tried using the CMakelists.txt file from the
>>>>>> >> >> 7th of
>>>>>> >> >> March
>>>>>> >> >> with the latest dev branch? Does it work?
>>>>>> >> >>
>>>>>> >> >> On 19 April 2016 at 12:35, Oeyvind Brandtsegg
>>>>>> >> >> 
>>>>>> >> >> wrote:
>>>>>> >> >>>
>>>>>> >> >>> No I'm sure I did not.
>>>>>> >> >>> The build system and the msys2 installation has been used only
>>>>>> >> >>> to
>>>>>> >> >>> build Csound, set up for that purpose during January/February.
>>>>>> >> >>> I
>>>>>> >> >>> haven't built anything else. And only build the dependencies in
>>>>>> >> >>> packages by using pkgbuilds in the csound repo.
>>>>>> >> >>> Could it be related to another package that was added (to the
>>>>>> >> >>> Csound
>>>>>> >> >>> repo) sometime during March? I did build and install those.
>>>>>> >> >>>
>>>>>> >> >>>
>>>>>> >> >>> 2016-04-19 13:26 GMT+02:00 Michael Gogins
>>>>>> >> >>> :
>>>>>> >> >>> > Very strange. Perhaps you built it some other way.
>>>>>> >> >>> >
>>>>>> >> >>> > Best,
>>>>>> >> >>> > Mike
>>>>>> >> >>> >
>>>>>> >> >>> > -----------------------------------------------------
>>>>>> >> >>> > Michael Gogins
>>>>>> >> >>> > Irreducible Productions
>>>>>> >> >>> > http://michaelgogins.tumblr.com
>>>>>> >> >>> > Michael dot Gogins at gmail dot com
>>>>>> >> >>> >
>>>>>> >> >>> >
>>>>>> >> >>> > On Tue, Apr 19, 2016 at 6:51 AM, Oeyvind Brandtsegg
>>>>>> >> >>> >  wrote:
>>>>>> >> >>> >> ... I checked the history for liblo/PKGBUILD and it has not
>>>>>> >> >>> >> changed,
>>>>>> >> >>> >> so I guess the issue is rooted somewwhere else
>>>>>> >> >>> >>
>>>>>> >> >>> >> 2016-04-19 12:35 GMT+02:00 Oeyvind Brandtsegg
>>>>>> >> >>> >> :
>>>>>> >> >>> >>> you mean to build liblo?
>>>>>> >> >>> >>> Yes, maybe that is a thing to try.
>>>>>> >> >>> >>>
>>>>>> >> >>> >>> 2016-04-19 12:29 GMT+02:00 Michael Gogins
>>>>>> >> >>> >>> :
>>>>>> >> >>> >>>> Thanks. Did you use the PKGBUILD script to build osc.dll?
>>>>>> >> >>> >>>> If so
>>>>>> >> >>> >>>> then
>>>>>> >> >>> >>>> we can
>>>>>> >> >>> >>>> just revert it.
>>>>>> >> >>> >>>>
>>>>>> >> >>> >>>> Best,
>>>>>> >> >>> >>>> Mike
>>>>>> >> >>> >>>>
>>>>>> >> >>> >>>> On Apr 19, 2016 6:00 AM, "Oeyvind Brandtsegg"
>>>>>> >> >>> >>>> 
>>>>>> >> >>> >>>> wrote:
>>>>>> >> >>> >>>>>
>>>>>> >> >>> >>>>> Here, the first one is my own build from March 7th, the
>>>>>> >> >>> >>>>> second
>>>>>> >> >>> >>>>> one
>>>>>> >> >>> >>>>> is
>>>>>> >> >>> >>>>> the Gogins rc2
>>>>>> >> >>> >>>>>
>>>>>> >> >>> >>>>> Administrator@HF-31335 MINGW64 /c/Program
>>>>>> >> >>> >>>>> Files/Csound6_x64_mymars/plugins64
>>>>>> >> >>> >>>>> $ ldd osc.dll
>>>>>> >> >>> >>>>>         ntdll.dll => /c/windows/SYSTEM32/ntdll.dll
>>>>>> >> >>> >>>>> (0x773c0000)
>>>>>> >> >>> >>>>>         kernel32.dll => /c/windows/system32/kernel32.dll
>>>>>> >> >>> >>>>> (0x771a0000)
>>>>>> >> >>> >>>>>         KERNELBASE.dll =>
>>>>>> >> >>> >>>>> /c/windows/system32/KERNELBASE.dll
>>>>>> >> >>> >>>>> (0x7fefd210000)
>>>>>> >> >>> >>>>>         fshook64.dll => /c/program files
>>>>>> >> >>> >>>>> (x86)/f-secure/hips/fshook64.dll (0x737
>>>>>> >> >>> >>>>>     d0000)
>>>>>> >> >>> >>>>>         PSAPI.DLL => /c/windows/system32/PSAPI.DLL
>>>>>> >> >>> >>>>> (0x77590000)
>>>>>> >> >>> >>>>>         ADVAPI32.dll => /c/windows/system32/ADVAPI32.dll
>>>>>> >> >>> >>>>> (0x7fefd6e0000)
>>>>>> >> >>> >>>>>         msvcrt.dll => /c/windows/system32/msvcrt.dll
>>>>>> >> >>> >>>>> (0x7fefe0f0000)
>>>>>> >> >>> >>>>>         sechost.dll => /c/windows/SYSTEM32/sechost.dll
>>>>>> >> >>> >>>>> (0x7fefdbd0000)
>>>>>> >> >>> >>>>>         RPCRT4.dll => /c/windows/system32/RPCRT4.dll
>>>>>> >> >>> >>>>> (0x7fefdfc0000)
>>>>>> >> >>> >>>>>         IPHLPAPI.DLL => /c/windows/system32/IPHLPAPI.DLL
>>>>>> >> >>> >>>>> (0x7fefa2c0000)
>>>>>> >> >>> >>>>>         NSI.dll => /c/windows/system32/NSI.dll
>>>>>> >> >>> >>>>> (0x7fefd810000)
>>>>>> >> >>> >>>>>         WINNSI.DLL => /c/windows/system32/WINNSI.DLL
>>>>>> >> >>> >>>>> (0x7fefa2a0000)
>>>>>> >> >>> >>>>>         USER32.dll => /c/windows/system32/USER32.dll
>>>>>> >> >>> >>>>> (0x772c0000)
>>>>>> >> >>> >>>>>         GDI32.dll => /c/windows/system32/GDI32.dll
>>>>>> >> >>> >>>>> (0x7fefe1e0000)
>>>>>> >> >>> >>>>>         LPK.dll => /c/windows/system32/LPK.dll
>>>>>> >> >>> >>>>> (0x7fefe4e0000)
>>>>>> >> >>> >>>>>         USP10.dll => /c/windows/system32/USP10.dll
>>>>>> >> >>> >>>>> (0x7fefe5d0000)
>>>>>> >> >>> >>>>>         WS2_32.dll => /c/windows/system32/WS2_32.dll
>>>>>> >> >>> >>>>> (0x7fefd7c0000)
>>>>>> >> >>> >>>>>         WSOCK32.dll => /c/windows/system32/WSOCK32.dll
>>>>>> >> >>> >>>>> (0x7fef00b0000)
>>>>>> >> >>> >>>>>         IMM32.DLL => /c/windows/system32/IMM32.DLL
>>>>>> >> >>> >>>>> (0x7fefe1b0000)
>>>>>> >> >>> >>>>>         MSCTF.dll => /c/windows/system32/MSCTF.dll
>>>>>> >> >>> >>>>> (0x7fefe830000)
>>>>>> >> >>> >>>>>
>>>>>> >> >>> >>>>>
>>>>>> >> >>> >>>>> Administrator@HF-31335 MINGW64 /c/Program
>>>>>> >> >>> >>>>> Files/Csound6_x64/plugins64
>>>>>> >> >>> >>>>> $ ldd osc.dll
>>>>>> >> >>> >>>>>         ntdll.dll => /c/windows/SYSTEM32/ntdll.dll
>>>>>> >> >>> >>>>> (0x773c0000)
>>>>>> >> >>> >>>>>         kernel32.dll => /c/windows/system32/kernel32.dll
>>>>>> >> >>> >>>>> (0x771a0000)
>>>>>> >> >>> >>>>>         KERNELBASE.dll =>
>>>>>> >> >>> >>>>> /c/windows/system32/KERNELBASE.dll
>>>>>> >> >>> >>>>> (0x7fefd210000)
>>>>>> >> >>> >>>>>         fshook64.dll => /c/program files
>>>>>> >> >>> >>>>> (x86)/f-secure/hips/fshook64.dll (0x737d0000)
>>>>>> >> >>> >>>>>         PSAPI.DLL => /c/windows/system32/PSAPI.DLL
>>>>>> >> >>> >>>>> (0x77590000)
>>>>>> >> >>> >>>>>         ADVAPI32.dll => /c/windows/system32/ADVAPI32.dll
>>>>>> >> >>> >>>>> (0x7fefd6e0000)
>>>>>> >> >>> >>>>>         msvcrt.dll => /c/windows/system32/msvcrt.dll
>>>>>> >> >>> >>>>> (0x7fefe0f0000)
>>>>>> >> >>> >>>>>         sechost.dll => /c/windows/SYSTEM32/sechost.dll
>>>>>> >> >>> >>>>> (0x7fefdbd0000)
>>>>>> >> >>> >>>>>         RPCRT4.dll => /c/windows/system32/RPCRT4.dll
>>>>>> >> >>> >>>>> (0x7fefdfc0000)
>>>>>> >> >>> >>>>>         IPHLPAPI.DLL => /c/windows/system32/IPHLPAPI.DLL
>>>>>> >> >>> >>>>> (0x7fefa2c0000)
>>>>>> >> >>> >>>>>         NSI.dll => /c/windows/system32/NSI.dll
>>>>>> >> >>> >>>>> (0x7fefd810000)
>>>>>> >> >>> >>>>>         WINNSI.DLL => /c/windows/system32/WINNSI.DLL
>>>>>> >> >>> >>>>> (0x7fefa2a0000)
>>>>>> >> >>> >>>>>         libwinpthread-1.dll =>
>>>>>> >> >>> >>>>> /mingw64/bin/libwinpthread-1.dll
>>>>>> >> >>> >>>>> (0x64940000)
>>>>>> >> >>> >>>>>         USER32.dll => /c/windows/system32/USER32.dll
>>>>>> >> >>> >>>>> (0x772c0000)
>>>>>> >> >>> >>>>>         GDI32.dll => /c/windows/system32/GDI32.dll
>>>>>> >> >>> >>>>> (0x7fefe1e0000)
>>>>>> >> >>> >>>>>         LPK.dll => /c/windows/system32/LPK.dll
>>>>>> >> >>> >>>>> (0x7fefe4e0000)
>>>>>> >> >>> >>>>>         USP10.dll => /c/windows/system32/USP10.dll
>>>>>> >> >>> >>>>> (0x7fefe5d0000)
>>>>>> >> >>> >>>>>         WS2_32.dll => /c/windows/system32/WS2_32.dll
>>>>>> >> >>> >>>>> (0x7fefd7c0000)
>>>>>> >> >>> >>>>>         WSOCK32.dll => /c/windows/system32/WSOCK32.dll
>>>>>> >> >>> >>>>> (0x7fef00b0000)
>>>>>> >> >>> >>>>>         IMM32.DLL => /c/windows/system32/IMM32.DLL
>>>>>> >> >>> >>>>> (0x7fefe1b0000)
>>>>>> >> >>> >>>>>         MSCTF.dll => /c/windows/system32/MSCTF.dll
>>>>>> >> >>> >>>>> (0x7fefe830000)
>>>>>> >> >>> >>>>>
>>>>>> >> >>> >>>>>
>>>>>> >> >>> >>>>> 2016-04-19 11:39 GMT+02:00 Michael Gogins
>>>>>> >> >>> >>>>> :
>>>>>> >> >>> >>>>> > What are the results of running ldd on both versions of
>>>>>> >> >>> >>>>> > osc.dll?
>>>>>> >> >>> >>>>> >
>>>>>> >> >>> >>>>> > Regards,
>>>>>> >> >>> >>>>> > Mike
>>>>>> >> >>> >>>>> >
>>>>>> >> >>> >>>>> > On Apr 19, 2016 2:57 AM, "Oeyvind Brandtsegg"
>>>>>> >> >>> >>>>> > 
>>>>>> >> >>> >>>>> > wrote:
>>>>>> >> >>> >>>>> >>
>>>>>> >> >>> >>>>> >> I don't know the fine details about the technicalities
>>>>>> >> >>> >>>>> >> of
>>>>>> >> >>> >>>>> >> this,
>>>>>> >> >>> >>>>> >> but I
>>>>>> >> >>> >>>>> >> can confirm that osc.dll was built and working in the
>>>>>> >> >>> >>>>> >> Csound
>>>>>> >> >>> >>>>> >> version I
>>>>>> >> >>> >>>>> >> built March 7th. I tested this again just now. Open
>>>>>> >> >>> >>>>> >> Sound
>>>>>> >> >>> >>>>> >> Control
>>>>>> >> >>> >>>>> >> also
>>>>>> >> >>> >>>>> >> confirmed working in this version. To me, this seems
>>>>>> >> >>> >>>>> >> like a
>>>>>> >> >>> >>>>> >> strong
>>>>>> >> >>> >>>>> >> indicator that it is indeed possible to build osc.dll
>>>>>> >> >>> >>>>> >> without
>>>>>> >> >>> >>>>> >> getting
>>>>>> >> >>> >>>>> >> the libpthread dependency. This version does not
>>>>>> >> >>> >>>>> >> complain
>>>>>> >> >>> >>>>> >> about
>>>>>> >> >>> >>>>> >> any
>>>>>> >> >>> >>>>> >> missing dlls, whereas the more recent ones show an
>>>>>> >> >>> >>>>> >> error
>>>>>> >> >>> >>>>> >> dialog
>>>>>> >> >>> >>>>> >> at
>>>>>> >> >>> >>>>> >> startup (unless the dlls are distributed in the
>>>>>> >> >>> >>>>> >> csound/bin
>>>>>> >> >>> >>>>> >> folder).
>>>>>> >> >>> >>>>> >> I think it is *very* important we get this sorted out,
>>>>>> >> >>> >>>>> >> as it
>>>>>> >> >>> >>>>> >> will
>>>>>> >> >>> >>>>> >> mean
>>>>>> >> >>> >>>>> >> the different frontends and other ways of acessing
>>>>>> >> >>> >>>>> >> Csound
>>>>>> >> >>> >>>>> >> will
>>>>>> >> >>> >>>>> >> otherwise interfere in unpredictable ways,
>>>>>> >> >>> >>>>> >>
>>>>>> >> >>> >>>>> >>
>>>>>> >> >>> >>>>> >> 2016-04-19 2:27 GMT+02:00 Michael Gogins
>>>>>> >> >>> >>>>> >> :
>>>>>> >> >>> >>>>> >> > LIblo requires pthreads. And that is in fact the
>>>>>> >> >>> >>>>> >> > source of
>>>>>> >> >>> >>>>> >> > this
>>>>>> >> >>> >>>>> >> > dependency as far as I can tell. I think the build
>>>>>> >> >>> >>>>> >> > recipe
>>>>>> >> >>> >>>>> >> > for
>>>>>> >> >>> >>>>> >> > liblo
>>>>>> >> >>> >>>>> >> > could be changed to use a static version of
>>>>>> >> >>> >>>>> >> > pthreads,
>>>>>> >> >>> >>>>> >> > however.
>>>>>> >> >>> >>>>> >> >
>>>>>> >> >>> >>>>> >> > By the way, I am not sure the static build idea is
>>>>>> >> >>> >>>>> >> > required
>>>>>> >> >>> >>>>> >> > for
>>>>>> >> >>> >>>>> >> > Csound. I was able to run CsoundVST about a year ago
>>>>>> >> >>> >>>>> >> > with
>>>>>> >> >>> >>>>> >> > Reaper in
>>>>>> >> >>> >>>>> >> > spite of DLL conflicts by ensuring that all DLLs
>>>>>> >> >>> >>>>> >> > required
>>>>>> >> >>> >>>>> >> > by
>>>>>> >> >>> >>>>> >> > Csound
>>>>>> >> >>> >>>>> >> > were in the VST bin directory.
>>>>>> >> >>> >>>>> >> >
>>>>>> >> >>> >>>>> >> > There also now appears to be a new crash in CsoundQt
>>>>>> >> >>> >>>>> >> > realted to
>>>>>> >> >>> >>>>> >> > the
>>>>>> >> >>> >>>>> >> > Csound MIDI module.
>>>>>> >> >>> >>>>> >> >
>>>>>> >> >>> >>>>> >> > The other issue I am looking at is a problem with
>>>>>> >> >>> >>>>> >> > line
>>>>>> >> >>> >>>>> >> > endings
>>>>>> >> >>> >>>>> >> > in
>>>>>> >> >>> >>>>> >> > CsoundQt. No matter what the number of line endings
>>>>>> >> >>> >>>>> >> > for
>>>>>> >> >>> >>>>> >> > each
>>>>>> >> >>> >>>>> >> > line
>>>>>> >> >>> >>>>> >> > keeps increasing, and it's impossible to turn off
>>>>>> >> >>> >>>>> >> > the
>>>>>> >> >>> >>>>> >> > Windows
>>>>>> >> >>> >>>>> >> > line
>>>>>> >> >>> >>>>> >> > endings. I think I should be able to fix this one
>>>>>> >> >>> >>>>> >> > though.
>>>>>> >> >>> >>>>> >> >
>>>>>> >> >>> >>>>> >> > Best,
>>>>>> >> >>> >>>>> >> > Mike
>>>>>> >> >>> >>>>> >> >
>>>>>> >> >>> >>>>> >> >
>>>>>> >> >>> >>>>> >> >
>>>>>> >> >>> >>>>> >> >
>>>>>> >> >>> >>>>> >> >
>>>>>> >> >>> >>>>> >> >
>>>>>> >> >>> >>>>> >> > -----------------------------------------------------
>>>>>> >> >>> >>>>> >> > Michael Gogins
>>>>>> >> >>> >>>>> >> > Irreducible Productions
>>>>>> >> >>> >>>>> >> > http://michaelgogins.tumblr.com
>>>>>> >> >>> >>>>> >> > Michael dot Gogins at gmail dot com
>>>>>> >> >>> >>>>> >> >
>>>>>> >> >>> >>>>> >> >
>>>>>> >> >>> >>>>> >> > On Mon, Apr 18, 2016 at 6:53 PM, Steven Yi
>>>>>> >> >>> >>>>> >> > 
>>>>>> >> >>> >>>>> >> > wrote:
>>>>>> >> >>> >>>>> >> >> Btw: we used to have separate thread
>>>>>> >> >>> >>>>> >> >> implementations. We
>>>>>> >> >>> >>>>> >> >> switched to
>>>>>> >> >>> >>>>> >> >> pthreads, but perhaps this was a mistake and we
>>>>>> >> >>> >>>>> >> >> should
>>>>>> >> >>> >>>>> >> >> have
>>>>>> >> >>> >>>>> >> >> kept the
>>>>>> >> >>> >>>>> >> >> implementations but reduced it down to just
>>>>>> >> >>> >>>>> >> >> pthreads,
>>>>>> >> >>> >>>>> >> >> win32,
>>>>>> >> >>> >>>>> >> >> and
>>>>>> >> >>> >>>>> >> >> no-op.
>>>>>> >> >>> >>>>> >> >> If
>>>>>> >> >>> >>>>> >> >> liblo requires pthreads though, not much to do
>>>>>> >> >>> >>>>> >> >> there about
>>>>>> >> >>> >>>>> >> >> that.
>>>>>> >> >>> >>>>> >> >>
>>>>>> >> >>> >>>>> >> >>
>>>>>> >> >>> >>>>> >> >> On Mon, Apr 18, 2016 at 6:46 PM Steven Yi
>>>>>> >> >>> >>>>> >> >> 
>>>>>> >> >>> >>>>> >> >> wrote:
>>>>>> >> >>> >>>>> >> >>>
>>>>>> >> >>> >>>>> >> >>> Have you looked at the Git history? I haven't been
>>>>>> >> >>> >>>>> >> >>> following
>>>>>> >> >>> >>>>> >> >>> that
>>>>>> >> >>> >>>>> >> >>> closely
>>>>>> >> >>> >>>>> >> >>> but the last build I did from yesterday had a
>>>>>> >> >>> >>>>> >> >>> problem
>>>>>> >> >>> >>>>> >> >>> where
>>>>>> >> >>> >>>>> >> >>> the
>>>>>> >> >>> >>>>> >> >>> Virtual
>>>>>> >> >>> >>>>> >> >>> keyboard didn't send any midi values. I suspect it
>>>>>> >> >>> >>>>> >> >>> has to
>>>>>> >> >>> >>>>> >> >>> do
>>>>>> >> >>> >>>>> >> >>> with
>>>>>> >> >>> >>>>> >> >>> recent
>>>>>> >> >>> >>>>> >> >>> lock changes, but I am just guessing. Besides
>>>>>> >> >>> >>>>> >> >>> these
>>>>>> >> >>> >>>>> >> >>> issues,
>>>>>> >> >>> >>>>> >> >>> what
>>>>>> >> >>> >>>>> >> >>> else
>>>>>> >> >>> >>>>> >> >>> is
>>>>>> >> >>> >>>>> >> >>> there?
>>>>>> >> >>> >>>>> >> >>> On Mon, Apr 18, 2016 at 6:38 PM Rory Walsh
>>>>>> >> >>> >>>>> >> >>> 
>>>>>> >> >>> >>>>> >> >>> wrote:
>>>>>> >> >>> >>>>> >> >>>>
>>>>>> >> >>> >>>>> >> >>>> Oeyvind and I have been trying to figure out what
>>>>>> >> >>> >>>>> >> >>>> happened
>>>>>> >> >>> >>>>> >> >>>> to the
>>>>>> >> >>> >>>>> >> >>>> Windows
>>>>>> >> >>> >>>>> >> >>>> build in mid-march which resulted in osc.dll
>>>>>> >> >>> >>>>> >> >>>> requiring
>>>>>> >> >>> >>>>> >> >>>> the
>>>>>> >> >>> >>>>> >> >>>> lib-pthread .dll
>>>>>> >> >>> >>>>> >> >>>> to be present in order to run. It was wasn't like
>>>>>> >> >>> >>>>> >> >>>> this
>>>>>> >> >>> >>>>> >> >>>> before
>>>>>> >> >>> >>>>> >> >>>> then,
>>>>>> >> >>> >>>>> >> >>>> but we
>>>>>> >> >>> >>>>> >> >>>> can't tell what happened to change it. Anyone
>>>>>> >> >>> >>>>> >> >>>> have any
>>>>>> >> >>> >>>>> >> >>>> ideas? I
>>>>>> >> >>> >>>>> >> >>>> can't
>>>>>> >> >>> >>>>> >> >>>> use
>>>>>> >> >>> >>>>> >> >>>> the canonical release of Csound lib to build
>>>>>> >> >>> >>>>> >> >>>> Cabbage
>>>>>> >> >>> >>>>> >> >>>> because
>>>>>> >> >>> >>>>> >> >>>> of
>>>>>> >> >>> >>>>> >> >>>> all
>>>>>> >> >>> >>>>> >> >>>> the .dll
>>>>>> >> >>> >>>>> >> >>>> dependencies, but I would love if we could still
>>>>>> >> >>> >>>>> >> >>>> try to
>>>>>> >> >>> >>>>> >> >>>> ensure as
>>>>>> >> >>> >>>>> >> >>>> much of
>>>>>> >> >>> >>>>> >> >>>> the plugin opcodes build statically as possible.
>>>>>> >> >>> >>>>> >>
>>>>>> >> >>> >>>>> >>
>>>>>> >> >>> >>>>> >>
>>>>>> >> >>> >>>>> >> --
>>>>>> >> >>> >>>>> >>
>>>>>> >> >>> >>>>> >> 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/
>>>>>> >> >>> >>>>> >> http://soundcloud.com/t-emp
>>>>>> >> >>> >>>>>
>>>>>> >> >>> >>>>>
>>>>>> >> >>> >>>>>
>>>>>> >> >>> >>>>> --
>>>>>> >> >>> >>>>>
>>>>>> >> >>> >>>>> 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/
>>>>>> >> >>> >>>>> http://soundcloud.com/t-emp
>>>>>> >> >>> >>>
>>>>>> >> >>> >>>
>>>>>> >> >>> >>>
>>>>>> >> >>> >>> --
>>>>>> >> >>> >>>
>>>>>> >> >>> >>> 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/
>>>>>> >> >>> >>> http://soundcloud.com/t-emp
>>>>>> >> >>> >>
>>>>>> >> >>> >>
>>>>>> >> >>> >>
>>>>>> >> >>> >> --
>>>>>> >> >>> >>
>>>>>> >> >>> >> 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/
>>>>>> >> >>> >> http://soundcloud.com/t-emp
>>>>>> >> >>>
>>>>>> >> >>>
>>>>>> >> >>>
>>>>>> >> >>> --
>>>>>> >> >>>
>>>>>> >> >>> 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/
>>>>>> >> >>> http://soundcloud.com/t-emp
>>>>>> >> >>
>>>>>> >> >>
>>>>>> >
>>>>>> >
>>>>
>>>>
>>>

Just to be clear, the pkgbuild thing is not the problem. No matter
what there will be a dependency on pthreads. The issue is whether
osc.dll links with pthreads static libraryt or pthreads dll.

It's not straightforward. If you build OSC.dll using the static liblo
then you must link OSC.dll with an external pthreads library which
might be static or might be dynamic. If you build OSC.dll usng the
dynamic liblo DLL then instead of OSC.dll linking with pthreads, it is
liblo that must link with pthreads and again that an be the static
pthreads library or the dynamic pthreads library. But we are linking
with the static liblo so it is OSC.dll that must link with pthreads
either statically or dynamically.

On Windows, a DLL cannot be linked with unresolved referebces, that is
the reason for what I said above. On other platforms you can link a
DLL with unresolved references, and the operating system will resolve
the unresolved references at run time if some other module loads the
required DLL.

Regards,
Mike

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


On Wed, Apr 20, 2016 at 12:58 PM, Rory Walsh  wrote:
> Thanks Mike. Much appreciated. Btw, I tried linking to a static version of
> the csound lib today, but I hit a load of libsndfile problems. Anyhow, I
> don't think I should be linking statically because it's in breach of the
> lgpl, although I'm pretty sure I'd get away with it ;)
>
> On 20 April 2016 at 17:54, Michael Gogins  wrote:
>>
>> This is the compiler command from my build:
>>
>> cd /D/msys64/home/restore/csound/mingw64/csound-mingw64/Opcodes &&
>> /D/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 -lpthread
>> -lwsock32 -lws2_32 -liphlpapi -lkernel32 -luser32 -lgdi32 -lwinspool
>> -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
>>
>> Note that liblo is linked statically but the other libraries after it
>> are linked dynamically. This is almost certainly the problem. I am
>> trying to figure out how to fix this.
>>
>> Best,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Tue, Apr 19, 2016 at 2:20 PM, Rory Walsh  wrote:
>> > I'm pretty sure that Ive used --static along with libpthread.dll in the
>> > past
>> > to statically build some of my apps. At least it got rid of the need for
>> > me
>> > to bundle pthread with my exe. Note that I was only able to do this with
>> > the
>> > pthread dll that shipped with the last version of mingw that I was
>> > using,
>> > pre msys2. I was never able to do it with the pthread I installed
>> > myself.
>> >
>> > On 19 April 2016 at 18:19, Michael Gogins 
>> > wrote:
>> >>
>> >> No. You can link directly but that is not statically.
>> >>
>> >> Best,
>> >> Mike
>> >>
>> >> On Apr 19, 2016 1:14 PM, "Rory Walsh"  wrote:
>> >>>
>> >>> You can link statically against the .dll as far as I remember?
>> >>>
>> >>> On 19 April 2016 at 18:13, Rory Walsh  wrote:
>> >>>>
>> >>>> I tried removing the --enable-shared in this file:
>> >>>>
>> >>>>
>> >>>> https://github.com/csound/csound/blob/develop/mingw64/packages/liblo/PKGBUILD#L20
>> >>>> But that didn't seem to work for me. I wouldn't mind someone else
>> >>>> trying
>> >>>> it, just in case I botched it up ;)
>> >>>>
>> >>>> On 19 April 2016 at 17:35, Michael Gogins 
>> >>>> wrote:
>> >>>>>
>> >>>>> Csound links pthreads statically. For some reason not quite
>> >>>>> identified,
>> >>>>> osc.dll links pthreads dynamically. It's probably just lacking the
>> >>>>> correct
>> >>>>> linker options.
>> >>>>>
>> >>>>> Best,
>> >>>>> Mike
>> >>>>>
>> >>>>> On Apr 19, 2016 12:26 PM, "Steven Yi"  wrote:
>> >>>>>>
>> >>>>>> I do see the dependency for osc.dll on libwinpthread-1.dll when
>> >>>>>> using
>> >>>>>> dependency walker. Oddly, not for csound64.dll. I tried removing
>> >>>>>> pthread as well as replacing with ${PTHREAD_LIBRARY} in
>> >>>>>> Opcodes/CMakeLists.txt and to no avail, the dependency still shows
>> >>>>>> up.
>> >>>>>>
>> >>>>>> I'm confused why libwinpthread-1.dll isn't showing up as a
>> >>>>>> dependency
>> >>>>>> for libcsound.
>> >>>>>>
>> >>>>>> On Tue, Apr 19, 2016 at 11:16 AM, Rory Walsh 
>> >>>>>> wrote:
>> >>>>>> > I just updated from the current tip, rebuilt everything and ran
>> >>>>>> > ldd,
>> >>>>>> > it
>> >>>>>> > shows no mention of libpthread. But when I run Cabbage on another
>> >>>>>> > machine, I
>> >>>>>> > get the pthread error unless I remove or rename osc.dll?
>> >>>>>> >
>> >>>>>> > On 19 April 2016 at 15:14, Steven Yi  wrote:
>> >>>>>> >>
>> >>>>>> >> Just FYI, the issue about loading the libraries is only
>> >>>>>> >> happening
>> >>>>>> >> in
>> >>>>>> >> Windows command prompt.  In the msys2 shell, OSC opcodes and
>> >>>>>> >> stkops
>> >>>>>> >> are loading fine.  OSC opcodes are working, and so is the
>> >>>>>> >> virtual
>> >>>>>> >> MIDI
>> >>>>>> >> (FLTK) keyboard.
>> >>>>>> >>
>> >>>>>> >> On Tue, Apr 19, 2016 at 9:49 AM, Steven Yi 
>> >>>>>> >> wrote:
>> >>>>>> >> > I'm looking at this now. Just FYI, my liblo build here has no
>> >>>>>> >> > winpthread:
>> >>>>>> >> >
>> >>>>>> >> > $ ldd liblo-7.dll
>> >>>>>> >> >         ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll
>> >>>>>> >> > (0x7ffd2fe20000)
>> >>>>>> >> >         KERNEL32.DLL => /c/WINDOWS/system32/KERNEL32.DLL
>> >>>>>> >> > (0x7ffd2d9c0000)
>> >>>>>> >> >         KERNELBASE.dll => /c/WINDOWS/system32/KERNELBASE.dll
>> >>>>>> >> > (0x7ffd2cfd0000)
>> >>>>>> >> >         apphelp.dll => /c/WINDOWS/system32/apphelp.dll
>> >>>>>> >> > (0x7ffd2ac30000)
>> >>>>>> >> >         msvcrt.dll => /c/WINDOWS/system32/msvcrt.dll
>> >>>>>> >> > (0x7ffd2d6e0000)
>> >>>>>> >> >
>> >>>>>> >> > and neither does my osc.dll:
>> >>>>>> >> >
>> >>>>>> >> >
>> >>>>>> >> > $ ldd osc.dll
>> >>>>>> >> >         ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll
>> >>>>>> >> > (0x7ffd2fe20000)
>> >>>>>> >> >         KERNEL32.DLL => /c/WINDOWS/system32/KERNEL32.DLL
>> >>>>>> >> > (0x7ffd2d9c0000)
>> >>>>>> >> >         KERNELBASE.dll => /c/WINDOWS/system32/KERNELBASE.dll
>> >>>>>> >> > (0x7ffd2cfd0000)
>> >>>>>> >> >         msvcrt.dll => /c/WINDOWS/system32/msvcrt.dll
>> >>>>>> >> > (0x7ffd2d6e0000)
>> >>>>>> >> >
>> >>>>>> >> > The liblo build is from January 14th. The osc.dll build is
>> >>>>>> >> > from
>> >>>>>> >> > April
>> >>>>>> >> > 11th. Then again, my build also doesn't even load the osc.dll
>> >>>>>> >> > opcode
>> >>>>>> >> > library:
>> >>>>>> >> >
>> >>>>>> >> >
>> >>>>>> >> >
>> >>>>>> >> >
>> >>>>>> >> > 'C:\Users\stevenyi\work\csound\csound\mingw64\csound-mingw64\stkops.dll'
>> >>>>>> >> > (-1)WARNING: could not open library
>> >>>>>> >> >
>> >>>>>> >> >
>> >>>>>> >> > 'C:\Users\stevenyi\work\csound\csound\mingw64\csound-mingw64\osc.dll'
>> >>>>>> >> > (-1)
>> >>>>>> >> >
>> >>>>>> >> > I am not sure what is going on now.
>> >>>>>> >> >
>> >>>>>> >> > On Tue, Apr 19, 2016 at 8:00 AM, Rory Walsh 
>> >>>>>> >> > wrote:
>> >>>>>> >> >> Exact same results here. I did look thought the git commit
>> >>>>>> >> >> history, and
>> >>>>>> >> >> the
>> >>>>>> >> >> only thing that really changed in the plugin CmakeLists.txt
>> >>>>>> >> >> was
>> >>>>>> >> >> the
>> >>>>>> >> >> addition
>> >>>>>> >> >> of some extra "find modules" stuff:
>> >>>>>> >> >>
>> >>>>>> >> >>
>> >>>>>> >> >>
>> >>>>>> >> >> https://github.com/csound/csound/commit/1d94318cf828e045c6c768889c55e467f1055d06
>> >>>>>> >> >> I think up to this point OSC.dll was still linking statically
>> >>>>>> >> >> to
>> >>>>>> >> >> pthread.
>> >>>>>> >> >> Oeyvind, have you tried using the CMakelists.txt file from
>> >>>>>> >> >> the
>> >>>>>> >> >> 7th of
>> >>>>>> >> >> March
>> >>>>>> >> >> with the latest dev branch? Does it work?
>> >>>>>> >> >>
>> >>>>>> >> >> On 19 April 2016 at 12:35, Oeyvind Brandtsegg
>> >>>>>> >> >> 
>> >>>>>> >> >> wrote:
>> >>>>>> >> >>>
>> >>>>>> >> >>> No I'm sure I did not.
>> >>>>>> >> >>> The build system and the msys2 installation has been used
>> >>>>>> >> >>> only
>> >>>>>> >> >>> to
>> >>>>>> >> >>> build Csound, set up for that purpose during
>> >>>>>> >> >>> January/February.
>> >>>>>> >> >>> I
>> >>>>>> >> >>> haven't built anything else. And only build the dependencies
>> >>>>>> >> >>> in
>> >>>>>> >> >>> packages by using pkgbuilds in the csound repo.
>> >>>>>> >> >>> Could it be related to another package that was added (to
>> >>>>>> >> >>> the
>> >>>>>> >> >>> Csound
>> >>>>>> >> >>> repo) sometime during March? I did build and install those.
>> >>>>>> >> >>>
>> >>>>>> >> >>>
>> >>>>>> >> >>> 2016-04-19 13:26 GMT+02:00 Michael Gogins
>> >>>>>> >> >>> :
>> >>>>>> >> >>> > Very strange. Perhaps you built it some other way.
>> >>>>>> >> >>> >
>> >>>>>> >> >>> > Best,
>> >>>>>> >> >>> > Mike
>> >>>>>> >> >>> >
>> >>>>>> >> >>> > -----------------------------------------------------
>> >>>>>> >> >>> > Michael Gogins
>> >>>>>> >> >>> > Irreducible Productions
>> >>>>>> >> >>> > http://michaelgogins.tumblr.com
>> >>>>>> >> >>> > Michael dot Gogins at gmail dot com
>> >>>>>> >> >>> >
>> >>>>>> >> >>> >
>> >>>>>> >> >>> > On Tue, Apr 19, 2016 at 6:51 AM, Oeyvind Brandtsegg
>> >>>>>> >> >>> >  wrote:
>> >>>>>> >> >>> >> ... I checked the history for liblo/PKGBUILD and it has
>> >>>>>> >> >>> >> not
>> >>>>>> >> >>> >> changed,
>> >>>>>> >> >>> >> so I guess the issue is rooted somewwhere else
>> >>>>>> >> >>> >>
>> >>>>>> >> >>> >> 2016-04-19 12:35 GMT+02:00 Oeyvind Brandtsegg
>> >>>>>> >> >>> >> :
>> >>>>>> >> >>> >>> you mean to build liblo?
>> >>>>>> >> >>> >>> Yes, maybe that is a thing to try.
>> >>>>>> >> >>> >>>
>> >>>>>> >> >>> >>> 2016-04-19 12:29 GMT+02:00 Michael Gogins
>> >>>>>> >> >>> >>> :
>> >>>>>> >> >>> >>>> Thanks. Did you use the PKGBUILD script to build
>> >>>>>> >> >>> >>>> osc.dll?
>> >>>>>> >> >>> >>>> If so
>> >>>>>> >> >>> >>>> then
>> >>>>>> >> >>> >>>> we can
>> >>>>>> >> >>> >>>> just revert it.
>> >>>>>> >> >>> >>>>
>> >>>>>> >> >>> >>>> Best,
>> >>>>>> >> >>> >>>> Mike
>> >>>>>> >> >>> >>>>
>> >>>>>> >> >>> >>>> On Apr 19, 2016 6:00 AM, "Oeyvind Brandtsegg"
>> >>>>>> >> >>> >>>> 
>> >>>>>> >> >>> >>>> wrote:
>> >>>>>> >> >>> >>>>>
>> >>>>>> >> >>> >>>>> Here, the first one is my own build from March 7th,
>> >>>>>> >> >>> >>>>> the
>> >>>>>> >> >>> >>>>> second
>> >>>>>> >> >>> >>>>> one
>> >>>>>> >> >>> >>>>> is
>> >>>>>> >> >>> >>>>> the Gogins rc2
>> >>>>>> >> >>> >>>>>
>> >>>>>> >> >>> >>>>> Administrator@HF-31335 MINGW64 /c/Program
>> >>>>>> >> >>> >>>>> Files/Csound6_x64_mymars/plugins64
>> >>>>>> >> >>> >>>>> $ ldd osc.dll
>> >>>>>> >> >>> >>>>>         ntdll.dll => /c/windows/SYSTEM32/ntdll.dll
>> >>>>>> >> >>> >>>>> (0x773c0000)
>> >>>>>> >> >>> >>>>>         kernel32.dll =>
>> >>>>>> >> >>> >>>>> /c/windows/system32/kernel32.dll
>> >>>>>> >> >>> >>>>> (0x771a0000)
>> >>>>>> >> >>> >>>>>         KERNELBASE.dll =>
>> >>>>>> >> >>> >>>>> /c/windows/system32/KERNELBASE.dll
>> >>>>>> >> >>> >>>>> (0x7fefd210000)
>> >>>>>> >> >>> >>>>>         fshook64.dll => /c/program files
>> >>>>>> >> >>> >>>>> (x86)/f-secure/hips/fshook64.dll (0x737
>> >>>>>> >> >>> >>>>>     d0000)
>> >>>>>> >> >>> >>>>>         PSAPI.DLL => /c/windows/system32/PSAPI.DLL
>> >>>>>> >> >>> >>>>> (0x77590000)
>> >>>>>> >> >>> >>>>>         ADVAPI32.dll =>
>> >>>>>> >> >>> >>>>> /c/windows/system32/ADVAPI32.dll
>> >>>>>> >> >>> >>>>> (0x7fefd6e0000)
>> >>>>>> >> >>> >>>>>         msvcrt.dll => /c/windows/system32/msvcrt.dll
>> >>>>>> >> >>> >>>>> (0x7fefe0f0000)
>> >>>>>> >> >>> >>>>>         sechost.dll => /c/windows/SYSTEM32/sechost.dll
>> >>>>>> >> >>> >>>>> (0x7fefdbd0000)
>> >>>>>> >> >>> >>>>>         RPCRT4.dll => /c/windows/system32/RPCRT4.dll
>> >>>>>> >> >>> >>>>> (0x7fefdfc0000)
>> >>>>>> >> >>> >>>>>         IPHLPAPI.DLL =>
>> >>>>>> >> >>> >>>>> /c/windows/system32/IPHLPAPI.DLL
>> >>>>>> >> >>> >>>>> (0x7fefa2c0000)
>> >>>>>> >> >>> >>>>>         NSI.dll => /c/windows/system32/NSI.dll
>> >>>>>> >> >>> >>>>> (0x7fefd810000)
>> >>>>>> >> >>> >>>>>         WINNSI.DLL => /c/windows/system32/WINNSI.DLL
>> >>>>>> >> >>> >>>>> (0x7fefa2a0000)
>> >>>>>> >> >>> >>>>>         USER32.dll => /c/windows/system32/USER32.dll
>> >>>>>> >> >>> >>>>> (0x772c0000)
>> >>>>>> >> >>> >>>>>         GDI32.dll => /c/windows/system32/GDI32.dll
>> >>>>>> >> >>> >>>>> (0x7fefe1e0000)
>> >>>>>> >> >>> >>>>>         LPK.dll => /c/windows/system32/LPK.dll
>> >>>>>> >> >>> >>>>> (0x7fefe4e0000)
>> >>>>>> >> >>> >>>>>         USP10.dll => /c/windows/system32/USP10.dll
>> >>>>>> >> >>> >>>>> (0x7fefe5d0000)
>> >>>>>> >> >>> >>>>>         WS2_32.dll => /c/windows/system32/WS2_32.dll
>> >>>>>> >> >>> >>>>> (0x7fefd7c0000)
>> >>>>>> >> >>> >>>>>         WSOCK32.dll => /c/windows/system32/WSOCK32.dll
>> >>>>>> >> >>> >>>>> (0x7fef00b0000)
>> >>>>>> >> >>> >>>>>         IMM32.DLL => /c/windows/system32/IMM32.DLL
>> >>>>>> >> >>> >>>>> (0x7fefe1b0000)
>> >>>>>> >> >>> >>>>>         MSCTF.dll => /c/windows/system32/MSCTF.dll
>> >>>>>> >> >>> >>>>> (0x7fefe830000)
>> >>>>>> >> >>> >>>>>
>> >>>>>> >> >>> >>>>>
>> >>>>>> >> >>> >>>>> Administrator@HF-31335 MINGW64 /c/Program
>> >>>>>> >> >>> >>>>> Files/Csound6_x64/plugins64
>> >>>>>> >> >>> >>>>> $ ldd osc.dll
>> >>>>>> >> >>> >>>>>         ntdll.dll => /c/windows/SYSTEM32/ntdll.dll
>> >>>>>> >> >>> >>>>> (0x773c0000)
>> >>>>>> >> >>> >>>>>         kernel32.dll =>
>> >>>>>> >> >>> >>>>> /c/windows/system32/kernel32.dll
>> >>>>>> >> >>> >>>>> (0x771a0000)
>> >>>>>> >> >>> >>>>>         KERNELBASE.dll =>
>> >>>>>> >> >>> >>>>> /c/windows/system32/KERNELBASE.dll
>> >>>>>> >> >>> >>>>> (0x7fefd210000)
>> >>>>>> >> >>> >>>>>         fshook64.dll => /c/program files
>> >>>>>> >> >>> >>>>> (x86)/f-secure/hips/fshook64.dll (0x737d0000)
>> >>>>>> >> >>> >>>>>         PSAPI.DLL => /c/windows/system32/PSAPI.DLL
>> >>>>>> >> >>> >>>>> (0x77590000)
>> >>>>>> >> >>> >>>>>         ADVAPI32.dll =>
>> >>>>>> >> >>> >>>>> /c/windows/system32/ADVAPI32.dll
>> >>>>>> >> >>> >>>>> (0x7fefd6e0000)
>> >>>>>> >> >>> >>>>>         msvcrt.dll => /c/windows/system32/msvcrt.dll
>> >>>>>> >> >>> >>>>> (0x7fefe0f0000)
>> >>>>>> >> >>> >>>>>         sechost.dll => /c/windows/SYSTEM32/sechost.dll
>> >>>>>> >> >>> >>>>> (0x7fefdbd0000)
>> >>>>>> >> >>> >>>>>         RPCRT4.dll => /c/windows/system32/RPCRT4.dll
>> >>>>>> >> >>> >>>>> (0x7fefdfc0000)
>> >>>>>> >> >>> >>>>>         IPHLPAPI.DLL =>
>> >>>>>> >> >>> >>>>> /c/windows/system32/IPHLPAPI.DLL
>> >>>>>> >> >>> >>>>> (0x7fefa2c0000)
>> >>>>>> >> >>> >>>>>         NSI.dll => /c/windows/system32/NSI.dll
>> >>>>>> >> >>> >>>>> (0x7fefd810000)
>> >>>>>> >> >>> >>>>>         WINNSI.DLL => /c/windows/system32/WINNSI.DLL
>> >>>>>> >> >>> >>>>> (0x7fefa2a0000)
>> >>>>>> >> >>> >>>>>         libwinpthread-1.dll =>
>> >>>>>> >> >>> >>>>> /mingw64/bin/libwinpthread-1.dll
>> >>>>>> >> >>> >>>>> (0x64940000)
>> >>>>>> >> >>> >>>>>         USER32.dll => /c/windows/system32/USER32.dll
>> >>>>>> >> >>> >>>>> (0x772c0000)
>> >>>>>> >> >>> >>>>>         GDI32.dll => /c/windows/system32/GDI32.dll
>> >>>>>> >> >>> >>>>> (0x7fefe1e0000)
>> >>>>>> >> >>> >>>>>         LPK.dll => /c/windows/system32/LPK.dll
>> >>>>>> >> >>> >>>>> (0x7fefe4e0000)
>> >>>>>> >> >>> >>>>>         USP10.dll => /c/windows/system32/USP10.dll
>> >>>>>> >> >>> >>>>> (0x7fefe5d0000)
>> >>>>>> >> >>> >>>>>         WS2_32.dll => /c/windows/system32/WS2_32.dll
>> >>>>>> >> >>> >>>>> (0x7fefd7c0000)
>> >>>>>> >> >>> >>>>>         WSOCK32.dll => /c/windows/system32/WSOCK32.dll
>> >>>>>> >> >>> >>>>> (0x7fef00b0000)
>> >>>>>> >> >>> >>>>>         IMM32.DLL => /c/windows/system32/IMM32.DLL
>> >>>>>> >> >>> >>>>> (0x7fefe1b0000)
>> >>>>>> >> >>> >>>>>         MSCTF.dll => /c/windows/system32/MSCTF.dll
>> >>>>>> >> >>> >>>>> (0x7fefe830000)
>> >>>>>> >> >>> >>>>>
>> >>>>>> >> >>> >>>>>
>> >>>>>> >> >>> >>>>> 2016-04-19 11:39 GMT+02:00 Michael Gogins
>> >>>>>> >> >>> >>>>> :
>> >>>>>> >> >>> >>>>> > What are the results of running ldd on both versions
>> >>>>>> >> >>> >>>>> > of
>> >>>>>> >> >>> >>>>> > osc.dll?
>> >>>>>> >> >>> >>>>> >
>> >>>>>> >> >>> >>>>> > Regards,
>> >>>>>> >> >>> >>>>> > Mike
>> >>>>>> >> >>> >>>>> >
>> >>>>>> >> >>> >>>>> > On Apr 19, 2016 2:57 AM, "Oeyvind Brandtsegg"
>> >>>>>> >> >>> >>>>> > 
>> >>>>>> >> >>> >>>>> > wrote:
>> >>>>>> >> >>> >>>>> >>
>> >>>>>> >> >>> >>>>> >> I don't know the fine details about the
>> >>>>>> >> >>> >>>>> >> technicalities
>> >>>>>> >> >>> >>>>> >> of
>> >>>>>> >> >>> >>>>> >> this,
>> >>>>>> >> >>> >>>>> >> but I
>> >>>>>> >> >>> >>>>> >> can confirm that osc.dll was built and working in
>> >>>>>> >> >>> >>>>> >> the
>> >>>>>> >> >>> >>>>> >> Csound
>> >>>>>> >> >>> >>>>> >> version I
>> >>>>>> >> >>> >>>>> >> built March 7th. I tested this again just now. Open
>> >>>>>> >> >>> >>>>> >> Sound
>> >>>>>> >> >>> >>>>> >> Control
>> >>>>>> >> >>> >>>>> >> also
>> >>>>>> >> >>> >>>>> >> confirmed working in this version. To me, this
>> >>>>>> >> >>> >>>>> >> seems
>> >>>>>> >> >>> >>>>> >> like a
>> >>>>>> >> >>> >>>>> >> strong
>> >>>>>> >> >>> >>>>> >> indicator that it is indeed possible to build
>> >>>>>> >> >>> >>>>> >> osc.dll
>> >>>>>> >> >>> >>>>> >> without
>> >>>>>> >> >>> >>>>> >> getting
>> >>>>>> >> >>> >>>>> >> the libpthread dependency. This version does not
>> >>>>>> >> >>> >>>>> >> complain
>> >>>>>> >> >>> >>>>> >> about
>> >>>>>> >> >>> >>>>> >> any
>> >>>>>> >> >>> >>>>> >> missing dlls, whereas the more recent ones show an
>> >>>>>> >> >>> >>>>> >> error
>> >>>>>> >> >>> >>>>> >> dialog
>> >>>>>> >> >>> >>>>> >> at
>> >>>>>> >> >>> >>>>> >> startup (unless the dlls are distributed in the
>> >>>>>> >> >>> >>>>> >> csound/bin
>> >>>>>> >> >>> >>>>> >> folder).
>> >>>>>> >> >>> >>>>> >> I think it is *very* important we get this sorted
>> >>>>>> >> >>> >>>>> >> out,
>> >>>>>> >> >>> >>>>> >> as it
>> >>>>>> >> >>> >>>>> >> will
>> >>>>>> >> >>> >>>>> >> mean
>> >>>>>> >> >>> >>>>> >> the different frontends and other ways of acessing
>> >>>>>> >> >>> >>>>> >> Csound
>> >>>>>> >> >>> >>>>> >> will
>> >>>>>> >> >>> >>>>> >> otherwise interfere in unpredictable ways,
>> >>>>>> >> >>> >>>>> >>
>> >>>>>> >> >>> >>>>> >>
>> >>>>>> >> >>> >>>>> >> 2016-04-19 2:27 GMT+02:00 Michael Gogins
>> >>>>>> >> >>> >>>>> >> :
>> >>>>>> >> >>> >>>>> >> > LIblo requires pthreads. And that is in fact the
>> >>>>>> >> >>> >>>>> >> > source of
>> >>>>>> >> >>> >>>>> >> > this
>> >>>>>> >> >>> >>>>> >> > dependency as far as I can tell. I think the
>> >>>>>> >> >>> >>>>> >> > build
>> >>>>>> >> >>> >>>>> >> > recipe
>> >>>>>> >> >>> >>>>> >> > for
>> >>>>>> >> >>> >>>>> >> > liblo
>> >>>>>> >> >>> >>>>> >> > could be changed to use a static version of
>> >>>>>> >> >>> >>>>> >> > pthreads,
>> >>>>>> >> >>> >>>>> >> > however.
>> >>>>>> >> >>> >>>>> >> >
>> >>>>>> >> >>> >>>>> >> > By the way, I am not sure the static build idea
>> >>>>>> >> >>> >>>>> >> > is
>> >>>>>> >> >>> >>>>> >> > required
>> >>>>>> >> >>> >>>>> >> > for
>> >>>>>> >> >>> >>>>> >> > Csound. I was able to run CsoundVST about a year
>> >>>>>> >> >>> >>>>> >> > ago
>> >>>>>> >> >>> >>>>> >> > with
>> >>>>>> >> >>> >>>>> >> > Reaper in
>> >>>>>> >> >>> >>>>> >> > spite of DLL conflicts by ensuring that all DLLs
>> >>>>>> >> >>> >>>>> >> > required
>> >>>>>> >> >>> >>>>> >> > by
>> >>>>>> >> >>> >>>>> >> > Csound
>> >>>>>> >> >>> >>>>> >> > were in the VST bin directory.
>> >>>>>> >> >>> >>>>> >> >
>> >>>>>> >> >>> >>>>> >> > There also now appears to be a new crash in
>> >>>>>> >> >>> >>>>> >> > CsoundQt
>> >>>>>> >> >>> >>>>> >> > realted to
>> >>>>>> >> >>> >>>>> >> > the
>> >>>>>> >> >>> >>>>> >> > Csound MIDI module.
>> >>>>>> >> >>> >>>>> >> >
>> >>>>>> >> >>> >>>>> >> > The other issue I am looking at is a problem with
>> >>>>>> >> >>> >>>>> >> > line
>> >>>>>> >> >>> >>>>> >> > endings
>> >>>>>> >> >>> >>>>> >> > in
>> >>>>>> >> >>> >>>>> >> > CsoundQt. No matter what the number of line
>> >>>>>> >> >>> >>>>> >> > endings
>> >>>>>> >> >>> >>>>> >> > for
>> >>>>>> >> >>> >>>>> >> > each
>> >>>>>> >> >>> >>>>> >> > line
>> >>>>>> >> >>> >>>>> >> > keeps increasing, and it's impossible to turn off
>> >>>>>> >> >>> >>>>> >> > the
>> >>>>>> >> >>> >>>>> >> > Windows
>> >>>>>> >> >>> >>>>> >> > line
>> >>>>>> >> >>> >>>>> >> > endings. I think I should be able to fix this one
>> >>>>>> >> >>> >>>>> >> > though.
>> >>>>>> >> >>> >>>>> >> >
>> >>>>>> >> >>> >>>>> >> > Best,
>> >>>>>> >> >>> >>>>> >> > Mike
>> >>>>>> >> >>> >>>>> >> >
>> >>>>>> >> >>> >>>>> >> >
>> >>>>>> >> >>> >>>>> >> >
>> >>>>>> >> >>> >>>>> >> >
>> >>>>>> >> >>> >>>>> >> >
>> >>>>>> >> >>> >>>>> >> >
>> >>>>>> >> >>> >>>>> >> >
>> >>>>>> >> >>> >>>>> >> > -----------------------------------------------------
>> >>>>>> >> >>> >>>>> >> > Michael Gogins
>> >>>>>> >> >>> >>>>> >> > Irreducible Productions
>> >>>>>> >> >>> >>>>> >> > http://michaelgogins.tumblr.com
>> >>>>>> >> >>> >>>>> >> > Michael dot Gogins at gmail dot com
>> >>>>>> >> >>> >>>>> >> >
>> >>>>>> >> >>> >>>>> >> >
>> >>>>>> >> >>> >>>>> >> > On Mon, Apr 18, 2016 at 6:53 PM, Steven Yi
>> >>>>>> >> >>> >>>>> >> > 
>> >>>>>> >> >>> >>>>> >> > wrote:
>> >>>>>> >> >>> >>>>> >> >> Btw: we used to have separate thread
>> >>>>>> >> >>> >>>>> >> >> implementations. We
>> >>>>>> >> >>> >>>>> >> >> switched to
>> >>>>>> >> >>> >>>>> >> >> pthreads, but perhaps this was a mistake and we
>> >>>>>> >> >>> >>>>> >> >> should
>> >>>>>> >> >>> >>>>> >> >> have
>> >>>>>> >> >>> >>>>> >> >> kept the
>> >>>>>> >> >>> >>>>> >> >> implementations but reduced it down to just
>> >>>>>> >> >>> >>>>> >> >> pthreads,
>> >>>>>> >> >>> >>>>> >> >> win32,
>> >>>>>> >> >>> >>>>> >> >> and
>> >>>>>> >> >>> >>>>> >> >> no-op.
>> >>>>>> >> >>> >>>>> >> >> If
>> >>>>>> >> >>> >>>>> >> >> liblo requires pthreads though, not much to do
>> >>>>>> >> >>> >>>>> >> >> there about
>> >>>>>> >> >>> >>>>> >> >> that.
>> >>>>>> >> >>> >>>>> >> >>
>> >>>>>> >> >>> >>>>> >> >>
>> >>>>>> >> >>> >>>>> >> >> On Mon, Apr 18, 2016 at 6:46 PM Steven Yi
>> >>>>>> >> >>> >>>>> >> >> 
>> >>>>>> >> >>> >>>>> >> >> wrote:
>> >>>>>> >> >>> >>>>> >> >>>
>> >>>>>> >> >>> >>>>> >> >>> Have you looked at the Git history? I haven't
>> >>>>>> >> >>> >>>>> >> >>> been
>> >>>>>> >> >>> >>>>> >> >>> following
>> >>>>>> >> >>> >>>>> >> >>> that
>> >>>>>> >> >>> >>>>> >> >>> closely
>> >>>>>> >> >>> >>>>> >> >>> but the last build I did from yesterday had a
>> >>>>>> >> >>> >>>>> >> >>> problem
>> >>>>>> >> >>> >>>>> >> >>> where
>> >>>>>> >> >>> >>>>> >> >>> the
>> >>>>>> >> >>> >>>>> >> >>> Virtual
>> >>>>>> >> >>> >>>>> >> >>> keyboard didn't send any midi values. I suspect
>> >>>>>> >> >>> >>>>> >> >>> it
>> >>>>>> >> >>> >>>>> >> >>> has to
>> >>>>>> >> >>> >>>>> >> >>> do
>> >>>>>> >> >>> >>>>> >> >>> with
>> >>>>>> >> >>> >>>>> >> >>> recent
>> >>>>>> >> >>> >>>>> >> >>> lock changes, but I am just guessing. Besides
>> >>>>>> >> >>> >>>>> >> >>> these
>> >>>>>> >> >>> >>>>> >> >>> issues,
>> >>>>>> >> >>> >>>>> >> >>> what
>> >>>>>> >> >>> >>>>> >> >>> else
>> >>>>>> >> >>> >>>>> >> >>> is
>> >>>>>> >> >>> >>>>> >> >>> there?
>> >>>>>> >> >>> >>>>> >> >>> On Mon, Apr 18, 2016 at 6:38 PM Rory Walsh
>> >>>>>> >> >>> >>>>> >> >>> 
>> >>>>>> >> >>> >>>>> >> >>> wrote:
>> >>>>>> >> >>> >>>>> >> >>>>
>> >>>>>> >> >>> >>>>> >> >>>> Oeyvind and I have been trying to figure out
>> >>>>>> >> >>> >>>>> >> >>>> what
>> >>>>>> >> >>> >>>>> >> >>>> happened
>> >>>>>> >> >>> >>>>> >> >>>> to the
>> >>>>>> >> >>> >>>>> >> >>>> Windows
>> >>>>>> >> >>> >>>>> >> >>>> build in mid-march which resulted in osc.dll
>> >>>>>> >> >>> >>>>> >> >>>> requiring
>> >>>>>> >> >>> >>>>> >> >>>> the
>> >>>>>> >> >>> >>>>> >> >>>> lib-pthread .dll
>> >>>>>> >> >>> >>>>> >> >>>> to be present in order to run. It was wasn't
>> >>>>>> >> >>> >>>>> >> >>>> like
>> >>>>>> >> >>> >>>>> >> >>>> this
>> >>>>>> >> >>> >>>>> >> >>>> before
>> >>>>>> >> >>> >>>>> >> >>>> then,
>> >>>>>> >> >>> >>>>> >> >>>> but we
>> >>>>>> >> >>> >>>>> >> >>>> can't tell what happened to change it. Anyone
>> >>>>>> >> >>> >>>>> >> >>>> have any
>> >>>>>> >> >>> >>>>> >> >>>> ideas? I
>> >>>>>> >> >>> >>>>> >> >>>> can't
>> >>>>>> >> >>> >>>>> >> >>>> use
>> >>>>>> >> >>> >>>>> >> >>>> the canonical release of Csound lib to build
>> >>>>>> >> >>> >>>>> >> >>>> Cabbage
>> >>>>>> >> >>> >>>>> >> >>>> because
>> >>>>>> >> >>> >>>>> >> >>>> of
>> >>>>>> >> >>> >>>>> >> >>>> all
>> >>>>>> >> >>> >>>>> >> >>>> the .dll
>> >>>>>> >> >>> >>>>> >> >>>> dependencies, but I would love if we could
>> >>>>>> >> >>> >>>>> >> >>>> still
>> >>>>>> >> >>> >>>>> >> >>>> try to
>> >>>>>> >> >>> >>>>> >> >>>> ensure as
>> >>>>>> >> >>> >>>>> >> >>>> much of
>> >>>>>> >> >>> >>>>> >> >>>> the plugin opcodes build statically as
>> >>>>>> >> >>> >>>>> >> >>>> possible.
>> >>>>>> >> >>> >>>>> >>
>> >>>>>> >> >>> >>>>> >>
>> >>>>>> >> >>> >>>>> >>
>> >>>>>> >> >>> >>>>> >> --
>> >>>>>> >> >>> >>>>> >>
>> >>>>>> >> >>> >>>>> >> 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/
>> >>>>>> >> >>> >>>>> >> http://soundcloud.com/t-emp
>> >>>>>> >> >>> >>>>>
>> >>>>>> >> >>> >>>>>
>> >>>>>> >> >>> >>>>>
>> >>>>>> >> >>> >>>>> --
>> >>>>>> >> >>> >>>>>
>> >>>>>> >> >>> >>>>> 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/
>> >>>>>> >> >>> >>>>> http://soundcloud.com/t-emp
>> >>>>>> >> >>> >>>
>> >>>>>> >> >>> >>>
>> >>>>>> >> >>> >>>
>> >>>>>> >> >>> >>> --
>> >>>>>> >> >>> >>>
>> >>>>>> >> >>> >>> 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/
>> >>>>>> >> >>> >>> http://soundcloud.com/t-emp
>> >>>>>> >> >>> >>
>> >>>>>> >> >>> >>
>> >>>>>> >> >>> >>
>> >>>>>> >> >>> >> --
>> >>>>>> >> >>> >>
>> >>>>>> >> >>> >> 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/
>> >>>>>> >> >>> >> http://soundcloud.com/t-emp
>> >>>>>> >> >>>
>> >>>>>> >> >>>
>> >>>>>> >> >>>
>> >>>>>> >> >>> --
>> >>>>>> >> >>>
>> >>>>>> >> >>> 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/
>> >>>>>> >> >>> http://soundcloud.com/t-emp
>> >>>>>> >> >>
>> >>>>>> >> >>
>> >>>>>> >
>> >>>>>> >
>> >>>>
>> >>>>
>> >>>
>> >
>

I think you are correct, OSC used to link with static liblo or static
pthread, but OSC also could have linked with dynamic liblo which in
turn was linked with static pthread. In your original ldd printout you
can see if the liblo DLL is listed, if not, then both liblo and
pthread were statically linked.

I believe I have identified and fixed the problem, soon to be booked
in, but I'm not happy with this situation. There are other plugins
where this might be happening. I will try to fix any that I see.

Regards,
Mike

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


On Wed, Apr 20, 2016 at 3:02 PM, Rory Walsh  wrote:
>> Just to be clear, the pkgbuild thing is not the problem. No matter
>> what there will be a dependency on pthreads. The issue is whether
>> osc.dll links with pthreads static libraryt or pthreads dll.
>
>
> This is clear.
>
>> It's not straightforward. If you build OSC.dll using the static liblo
>> then you must link OSC.dll with an external pthreads library which
>> might be static or might be dynamic. If you build OSC.dll usng the
>> dynamic liblo DLL then instead of OSC.dll linking with pthreads, it is
>> liblo that must link with pthreads and again that an be the static
>> pthreads library or the dynamic pthreads library. But we are linking
>> with the static liblo so it is OSC.dll that must link with pthreads
>> either statically or dynamically.
>
>
> Ok. Thanks for the clarification. Is this what was happening then in the
> early days of the msys2 build, i.e, OSC was linked with a static liblo, and

More on this, and it's fairly important.

CMake's default behavior in earlier versions was to link with
libraries found in "standard" locations, even if the full pathname to
the library was passed to target_link_libraries. Needless to say, this
is very confusing, because it can easily mean that one sets a full
pathname to a static library in target_link_libraries and ends up
linking with the dynamic version of that library anyway because gcc's
default behavior is to prefer dynamic libraries.

I have added the following code at the head of CMakeLists.txt to fix
this problem:

# Instruct CMake to use specified pathnames for target_link_library even if
# another version of the specified library exists in a standard location.
if(WIN32)
    cmake_policy(SET CMP0060 NEW)
endif()

Regards,
Mike



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


On Wed, Apr 20, 2016 at 3:20 PM, Michael Gogins
 wrote:
> I think you are correct, OSC used to link with static liblo or static
> pthread, but OSC also could have linked with dynamic liblo which in
> turn was linked with static pthread. In your original ldd printout you
> can see if the liblo DLL is listed, if not, then both liblo and
> pthread were statically linked.
>
> I believe I have identified and fixed the problem, soon to be booked
> in, but I'm not happy with this situation. There are other plugins
> where this might be happening. I will try to fix any that I see.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Wed, Apr 20, 2016 at 3:02 PM, Rory Walsh  wrote:
>>> Just to be clear, the pkgbuild thing is not the problem. No matter
>>> what there will be a dependency on pthreads. The issue is whether
>>> osc.dll links with pthreads static libraryt or pthreads dll.
>>
>>
>> This is clear.
>>
>>> It's not straightforward. If you build OSC.dll using the static liblo
>>> then you must link OSC.dll with an external pthreads library which
>>> might be static or might be dynamic. If you build OSC.dll usng the
>>> dynamic liblo DLL then instead of OSC.dll linking with pthreads, it is
>>> liblo that must link with pthreads and again that an be the static
>>> pthreads library or the dynamic pthreads library. But we are linking
>>> with the static liblo so it is OSC.dll that must link with pthreads
>>> either statically or dynamically.
>>
>>
>> Ok. Thanks for the clarification. Is this what was happening then in the
>> early days of the msys2 build, i.e, OSC was linked with a static liblo, and

Hi Michael,

I just tried a build and things seem to  have gotten worse. Now when I
run Csound I get and error that libsndfile-1.dll can not be found.  I
will try a clean and rebuild now.

steven


On Thu, Apr 21, 2016 at 11:56 AM, Michael Gogins
 wrote:
> More on this, and it's fairly important.
>
> CMake's default behavior in earlier versions was to link with
> libraries found in "standard" locations, even if the full pathname to
> the library was passed to target_link_libraries. Needless to say, this
> is very confusing, because it can easily mean that one sets a full
> pathname to a static library in target_link_libraries and ends up
> linking with the dynamic version of that library anyway because gcc's
> default behavior is to prefer dynamic libraries.
>
> I have added the following code at the head of CMakeLists.txt to fix
> this problem:
>
> # Instruct CMake to use specified pathnames for target_link_library even if
> # another version of the specified library exists in a standard location.
> if(WIN32)
>     cmake_policy(SET CMP0060 NEW)
> endif()
>
> Regards,
> Mike
>
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Wed, Apr 20, 2016 at 3:20 PM, Michael Gogins
>  wrote:
>> I think you are correct, OSC used to link with static liblo or static
>> pthread, but OSC also could have linked with dynamic liblo which in
>> turn was linked with static pthread. In your original ldd printout you
>> can see if the liblo DLL is listed, if not, then both liblo and
>> pthread were statically linked.
>>
>> I believe I have identified and fixed the problem, soon to be booked
>> in, but I'm not happy with this situation. There are other plugins
>> where this might be happening. I will try to fix any that I see.
>>
>> Regards,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Wed, Apr 20, 2016 at 3:02 PM, Rory Walsh  wrote:
>>>> Just to be clear, the pkgbuild thing is not the problem. No matter
>>>> what there will be a dependency on pthreads. The issue is whether
>>>> osc.dll links with pthreads static libraryt or pthreads dll.
>>>
>>>
>>> This is clear.
>>>
>>>> It's not straightforward. If you build OSC.dll using the static liblo
>>>> then you must link OSC.dll with an external pthreads library which
>>>> might be static or might be dynamic. If you build OSC.dll usng the
>>>> dynamic liblo DLL then instead of OSC.dll linking with pthreads, it is
>>>> liblo that must link with pthreads and again that an be the static
>>>> pthreads library or the dynamic pthreads library. But we are linking
>>>> with the static liblo so it is OSC.dll that must link with pthreads
>>>> either statically or dynamically.
>>>
>>>
>>> Ok. Thanks for the clarification. Is this what was happening then in the
>>> early days of the msys2 build, i.e, OSC was linked with a static liblo, and

FYI: Dependency walker now shows a link from csound64.dll to libsndfile-1.dll.

On Thu, Apr 21, 2016 at 12:10 PM, Steven Yi  wrote:
> Hi Michael,
>
> I just tried a build and things seem to  have gotten worse. Now when I
> run Csound I get and error that libsndfile-1.dll can not be found.  I
> will try a clean and rebuild now.
>
> steven
>
>
> On Thu, Apr 21, 2016 at 11:56 AM, Michael Gogins
>  wrote:
>> More on this, and it's fairly important.
>>
>> CMake's default behavior in earlier versions was to link with
>> libraries found in "standard" locations, even if the full pathname to
>> the library was passed to target_link_libraries. Needless to say, this
>> is very confusing, because it can easily mean that one sets a full
>> pathname to a static library in target_link_libraries and ends up
>> linking with the dynamic version of that library anyway because gcc's
>> default behavior is to prefer dynamic libraries.
>>
>> I have added the following code at the head of CMakeLists.txt to fix
>> this problem:
>>
>> # Instruct CMake to use specified pathnames for target_link_library even if
>> # another version of the specified library exists in a standard location.
>> if(WIN32)
>>     cmake_policy(SET CMP0060 NEW)
>> endif()
>>
>> Regards,
>> Mike
>>
>>
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Wed, Apr 20, 2016 at 3:20 PM, Michael Gogins
>>  wrote:
>>> I think you are correct, OSC used to link with static liblo or static
>>> pthread, but OSC also could have linked with dynamic liblo which in
>>> turn was linked with static pthread. In your original ldd printout you
>>> can see if the liblo DLL is listed, if not, then both liblo and
>>> pthread were statically linked.
>>>
>>> I believe I have identified and fixed the problem, soon to be booked
>>> in, but I'm not happy with this situation. There are other plugins
>>> where this might be happening. I will try to fix any that I see.
>>>
>>> Regards,
>>> Mike
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Wed, Apr 20, 2016 at 3:02 PM, Rory Walsh  wrote:
>>>>> Just to be clear, the pkgbuild thing is not the problem. No matter
>>>>> what there will be a dependency on pthreads. The issue is whether
>>>>> osc.dll links with pthreads static libraryt or pthreads dll.
>>>>
>>>>
>>>> This is clear.
>>>>
>>>>> It's not straightforward. If you build OSC.dll using the static liblo
>>>>> then you must link OSC.dll with an external pthreads library which
>>>>> might be static or might be dynamic. If you build OSC.dll usng the
>>>>> dynamic liblo DLL then instead of OSC.dll linking with pthreads, it is
>>>>> liblo that must link with pthreads and again that an be the static
>>>>> pthreads library or the dynamic pthreads library. But we are linking
>>>>> with the static liblo so it is OSC.dll that must link with pthreads
>>>>> either statically or dynamically.
>>>>
>>>>
>>>> Ok. Thanks for the clarification. Is this what was happening then in the
>>>> early days of the msys2 build, i.e, OSC was linked with a static liblo, and

Did we not always link to the dynamic libsndfile?

Best,
Mike

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


On Thu, Apr 21, 2016 at 12:23 PM, Steven Yi  wrote:
> FYI: Dependency walker now shows a link from csound64.dll to libsndfile-1.dll.
>
> On Thu, Apr 21, 2016 at 12:10 PM, Steven Yi  wrote:
>> Hi Michael,
>>
>> I just tried a build and things seem to  have gotten worse. Now when I
>> run Csound I get and error that libsndfile-1.dll can not be found.  I
>> will try a clean and rebuild now.
>>
>> steven
>>
>>
>> On Thu, Apr 21, 2016 at 11:56 AM, Michael Gogins
>>  wrote:
>>> More on this, and it's fairly important.
>>>
>>> CMake's default behavior in earlier versions was to link with
>>> libraries found in "standard" locations, even if the full pathname to
>>> the library was passed to target_link_libraries. Needless to say, this
>>> is very confusing, because it can easily mean that one sets a full
>>> pathname to a static library in target_link_libraries and ends up
>>> linking with the dynamic version of that library anyway because gcc's
>>> default behavior is to prefer dynamic libraries.
>>>
>>> I have added the following code at the head of CMakeLists.txt to fix
>>> this problem:
>>>
>>> # Instruct CMake to use specified pathnames for target_link_library even if
>>> # another version of the specified library exists in a standard location.
>>> if(WIN32)
>>>     cmake_policy(SET CMP0060 NEW)
>>> endif()
>>>
>>> Regards,
>>> Mike
>>>
>>>
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Wed, Apr 20, 2016 at 3:20 PM, Michael Gogins
>>>  wrote:
>>>> I think you are correct, OSC used to link with static liblo or static
>>>> pthread, but OSC also could have linked with dynamic liblo which in
>>>> turn was linked with static pthread. In your original ldd printout you
>>>> can see if the liblo DLL is listed, if not, then both liblo and
>>>> pthread were statically linked.
>>>>
>>>> I believe I have identified and fixed the problem, soon to be booked
>>>> in, but I'm not happy with this situation. There are other plugins
>>>> where this might be happening. I will try to fix any that I see.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> -----------------------------------------------------
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://michaelgogins.tumblr.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>>
>>>> On Wed, Apr 20, 2016 at 3:02 PM, Rory Walsh  wrote:
>>>>>> Just to be clear, the pkgbuild thing is not the problem. No matter
>>>>>> what there will be a dependency on pthreads. The issue is whether
>>>>>> osc.dll links with pthreads static libraryt or pthreads dll.
>>>>>
>>>>>
>>>>> This is clear.
>>>>>
>>>>>> It's not straightforward. If you build OSC.dll using the static liblo
>>>>>> then you must link OSC.dll with an external pthreads library which
>>>>>> might be static or might be dynamic. If you build OSC.dll usng the
>>>>>> dynamic liblo DLL then instead of OSC.dll linking with pthreads, it is
>>>>>> liblo that must link with pthreads and again that an be the static
>>>>>> pthreads library or the dynamic pthreads library. But we are linking
>>>>>> with the static liblo so it is OSC.dll that must link with pthreads
>>>>>> either statically or dynamically.
>>>>>
>>>>>
>>>>> Ok. Thanks for the clarification. Is this what was happening then in the
>>>>> early days of the msys2 build, i.e, OSC was linked with a static liblo, and

Not at all.  One of the first things I worked on for mingw64 was
getting libsndfile (and its supporting libraries, as this is all
static) to link to libcsound.

On Thu, Apr 21, 2016 at 1:14 PM, Michael Gogins
 wrote:
> Did we not always link to the dynamic libsndfile?
>
> Best,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Thu, Apr 21, 2016 at 12:23 PM, Steven Yi  wrote:
>> FYI: Dependency walker now shows a link from csound64.dll to libsndfile-1.dll.
>>
>> On Thu, Apr 21, 2016 at 12:10 PM, Steven Yi  wrote:
>>> Hi Michael,
>>>
>>> I just tried a build and things seem to  have gotten worse. Now when I
>>> run Csound I get and error that libsndfile-1.dll can not be found.  I
>>> will try a clean and rebuild now.
>>>
>>> steven
>>>
>>>
>>> On Thu, Apr 21, 2016 at 11:56 AM, Michael Gogins
>>>  wrote:
>>>> More on this, and it's fairly important.
>>>>
>>>> CMake's default behavior in earlier versions was to link with
>>>> libraries found in "standard" locations, even if the full pathname to
>>>> the library was passed to target_link_libraries. Needless to say, this
>>>> is very confusing, because it can easily mean that one sets a full
>>>> pathname to a static library in target_link_libraries and ends up
>>>> linking with the dynamic version of that library anyway because gcc's
>>>> default behavior is to prefer dynamic libraries.
>>>>
>>>> I have added the following code at the head of CMakeLists.txt to fix
>>>> this problem:
>>>>
>>>> # Instruct CMake to use specified pathnames for target_link_library even if
>>>> # another version of the specified library exists in a standard location.
>>>> if(WIN32)
>>>>     cmake_policy(SET CMP0060 NEW)
>>>> endif()
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>>
>>>>
>>>> -----------------------------------------------------
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://michaelgogins.tumblr.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>>
>>>> On Wed, Apr 20, 2016 at 3:20 PM, Michael Gogins
>>>>  wrote:
>>>>> I think you are correct, OSC used to link with static liblo or static
>>>>> pthread, but OSC also could have linked with dynamic liblo which in
>>>>> turn was linked with static pthread. In your original ldd printout you
>>>>> can see if the liblo DLL is listed, if not, then both liblo and
>>>>> pthread were statically linked.
>>>>>
>>>>> I believe I have identified and fixed the problem, soon to be booked
>>>>> in, but I'm not happy with this situation. There are other plugins
>>>>> where this might be happening. I will try to fix any that I see.
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> -----------------------------------------------------
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://michaelgogins.tumblr.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>>
>>>>> On Wed, Apr 20, 2016 at 3:02 PM, Rory Walsh  wrote:
>>>>>>> Just to be clear, the pkgbuild thing is not the problem. No matter
>>>>>>> what there will be a dependency on pthreads. The issue is whether
>>>>>>> osc.dll links with pthreads static libraryt or pthreads dll.
>>>>>>
>>>>>>
>>>>>> This is clear.
>>>>>>
>>>>>>> It's not straightforward. If you build OSC.dll using the static liblo
>>>>>>> then you must link OSC.dll with an external pthreads library which
>>>>>>> might be static or might be dynamic. If you build OSC.dll usng the
>>>>>>> dynamic liblo DLL then instead of OSC.dll linking with pthreads, it is
>>>>>>> liblo that must link with pthreads and again that an be the static
>>>>>>> pthreads library or the dynamic pthreads library. But we are linking
>>>>>>> with the static liblo so it is OSC.dll that must link with pthreads
>>>>>>> either statically or dynamically.
>>>>>>
>>>>>>
>>>>>> Ok. Thanks for the clarification. Is this what was happening then in the
>>>>>> early days of the msys2 build, i.e, OSC was linked with a static liblo, and

I think the policy change must be the cause of the problem.  I'm
guessing the finder for sndfile would have previously found the dll,
but at link time, would have used -lsndfile, which would have been
affected by the -static flag. That's my guess at least.  As it is now,
I'm getting dynamic links for most things. I don't think this policy
change is the right answer for this problem.

On Thu, Apr 21, 2016 at 3:02 PM, Steven Yi  wrote:
> Not at all.  One of the first things I worked on for mingw64 was
> getting libsndfile (and its supporting libraries, as this is all
> static) to link to libcsound.
>
> On Thu, Apr 21, 2016 at 1:14 PM, Michael Gogins
>  wrote:
>> Did we not always link to the dynamic libsndfile?
>>
>> Best,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Thu, Apr 21, 2016 at 12:23 PM, Steven Yi  wrote:
>>> FYI: Dependency walker now shows a link from csound64.dll to libsndfile-1.dll.
>>>
>>> On Thu, Apr 21, 2016 at 12:10 PM, Steven Yi  wrote:
>>>> Hi Michael,
>>>>
>>>> I just tried a build and things seem to  have gotten worse. Now when I
>>>> run Csound I get and error that libsndfile-1.dll can not be found.  I
>>>> will try a clean and rebuild now.
>>>>
>>>> steven
>>>>
>>>>
>>>> On Thu, Apr 21, 2016 at 11:56 AM, Michael Gogins
>>>>  wrote:
>>>>> More on this, and it's fairly important.
>>>>>
>>>>> CMake's default behavior in earlier versions was to link with
>>>>> libraries found in "standard" locations, even if the full pathname to
>>>>> the library was passed to target_link_libraries. Needless to say, this
>>>>> is very confusing, because it can easily mean that one sets a full
>>>>> pathname to a static library in target_link_libraries and ends up
>>>>> linking with the dynamic version of that library anyway because gcc's
>>>>> default behavior is to prefer dynamic libraries.
>>>>>
>>>>> I have added the following code at the head of CMakeLists.txt to fix
>>>>> this problem:
>>>>>
>>>>> # Instruct CMake to use specified pathnames for target_link_library even if
>>>>> # another version of the specified library exists in a standard location.
>>>>> if(WIN32)
>>>>>     cmake_policy(SET CMP0060 NEW)
>>>>> endif()
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>> -----------------------------------------------------
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://michaelgogins.tumblr.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>>
>>>>> On Wed, Apr 20, 2016 at 3:20 PM, Michael Gogins
>>>>>  wrote:
>>>>>> I think you are correct, OSC used to link with static liblo or static
>>>>>> pthread, but OSC also could have linked with dynamic liblo which in
>>>>>> turn was linked with static pthread. In your original ldd printout you
>>>>>> can see if the liblo DLL is listed, if not, then both liblo and
>>>>>> pthread were statically linked.
>>>>>>
>>>>>> I believe I have identified and fixed the problem, soon to be booked
>>>>>> in, but I'm not happy with this situation. There are other plugins
>>>>>> where this might be happening. I will try to fix any that I see.
>>>>>>
>>>>>> Regards,
>>>>>> Mike
>>>>>>
>>>>>> -----------------------------------------------------
>>>>>> Michael Gogins
>>>>>> Irreducible Productions
>>>>>> http://michaelgogins.tumblr.com
>>>>>> Michael dot Gogins at gmail dot com
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 20, 2016 at 3:02 PM, Rory Walsh  wrote:
>>>>>>>> Just to be clear, the pkgbuild thing is not the problem. No matter
>>>>>>>> what there will be a dependency on pthreads. The issue is whether
>>>>>>>> osc.dll links with pthreads static libraryt or pthreads dll.
>>>>>>>
>>>>>>>
>>>>>>> This is clear.
>>>>>>>
>>>>>>>> It's not straightforward. If you build OSC.dll using the static liblo
>>>>>>>> then you must link OSC.dll with an external pthreads library which
>>>>>>>> might be static or might be dynamic. If you build OSC.dll usng the
>>>>>>>> dynamic liblo DLL then instead of OSC.dll linking with pthreads, it is
>>>>>>>> liblo that must link with pthreads and again that an be the static
>>>>>>>> pthreads library or the dynamic pthreads library. But we are linking
>>>>>>>> with the static liblo so it is OSC.dll that must link with pthreads
>>>>>>>> either statically or dynamically.
>>>>>>>
>>>>>>>
>>>>>>> Ok. Thanks for the clarification. Is this what was happening then in the
>>>>>>> early days of the msys2 build, i.e, OSC was linked with a static liblo, and

FYI: commenting out the policy change *does* fix the problem for me,
at least the sndfile-1 related issue. I do get the osc and stkops not
loading again, but this is a marked improvement over the previous
situation.

On Thu, Apr 21, 2016 at 3:08 PM, Steven Yi  wrote:
> I think the policy change must be the cause of the problem.  I'm
> guessing the finder for sndfile would have previously found the dll,
> but at link time, would have used -lsndfile, which would have been
> affected by the -static flag. That's my guess at least.  As it is now,
> I'm getting dynamic links for most things. I don't think this policy
> change is the right answer for this problem.
>
> On Thu, Apr 21, 2016 at 3:02 PM, Steven Yi  wrote:
>> Not at all.  One of the first things I worked on for mingw64 was
>> getting libsndfile (and its supporting libraries, as this is all
>> static) to link to libcsound.
>>
>> On Thu, Apr 21, 2016 at 1:14 PM, Michael Gogins
>>  wrote:
>>> Did we not always link to the dynamic libsndfile?
>>>
>>> Best,
>>> Mike
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Thu, Apr 21, 2016 at 12:23 PM, Steven Yi  wrote:
>>>> FYI: Dependency walker now shows a link from csound64.dll to libsndfile-1.dll.
>>>>
>>>> On Thu, Apr 21, 2016 at 12:10 PM, Steven Yi  wrote:
>>>>> Hi Michael,
>>>>>
>>>>> I just tried a build and things seem to  have gotten worse. Now when I
>>>>> run Csound I get and error that libsndfile-1.dll can not be found.  I
>>>>> will try a clean and rebuild now.
>>>>>
>>>>> steven
>>>>>
>>>>>
>>>>> On Thu, Apr 21, 2016 at 11:56 AM, Michael Gogins
>>>>>  wrote:
>>>>>> More on this, and it's fairly important.
>>>>>>
>>>>>> CMake's default behavior in earlier versions was to link with
>>>>>> libraries found in "standard" locations, even if the full pathname to
>>>>>> the library was passed to target_link_libraries. Needless to say, this
>>>>>> is very confusing, because it can easily mean that one sets a full
>>>>>> pathname to a static library in target_link_libraries and ends up
>>>>>> linking with the dynamic version of that library anyway because gcc's
>>>>>> default behavior is to prefer dynamic libraries.
>>>>>>
>>>>>> I have added the following code at the head of CMakeLists.txt to fix
>>>>>> this problem:
>>>>>>
>>>>>> # Instruct CMake to use specified pathnames for target_link_library even if
>>>>>> # another version of the specified library exists in a standard location.
>>>>>> if(WIN32)
>>>>>>     cmake_policy(SET CMP0060 NEW)
>>>>>> endif()
>>>>>>
>>>>>> Regards,
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------
>>>>>> Michael Gogins
>>>>>> Irreducible Productions
>>>>>> http://michaelgogins.tumblr.com
>>>>>> Michael dot Gogins at gmail dot com
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 20, 2016 at 3:20 PM, Michael Gogins
>>>>>>  wrote:
>>>>>>> I think you are correct, OSC used to link with static liblo or static
>>>>>>> pthread, but OSC also could have linked with dynamic liblo which in
>>>>>>> turn was linked with static pthread. In your original ldd printout you
>>>>>>> can see if the liblo DLL is listed, if not, then both liblo and
>>>>>>> pthread were statically linked.
>>>>>>>
>>>>>>> I believe I have identified and fixed the problem, soon to be booked
>>>>>>> in, but I'm not happy with this situation. There are other plugins
>>>>>>> where this might be happening. I will try to fix any that I see.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Mike
>>>>>>>
>>>>>>> -----------------------------------------------------
>>>>>>> Michael Gogins
>>>>>>> Irreducible Productions
>>>>>>> http://michaelgogins.tumblr.com
>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Apr 20, 2016 at 3:02 PM, Rory Walsh  wrote:
>>>>>>>>> Just to be clear, the pkgbuild thing is not the problem. No matter
>>>>>>>>> what there will be a dependency on pthreads. The issue is whether
>>>>>>>>> osc.dll links with pthreads static libraryt or pthreads dll.
>>>>>>>>
>>>>>>>>
>>>>>>>> This is clear.
>>>>>>>>
>>>>>>>>> It's not straightforward. If you build OSC.dll using the static liblo
>>>>>>>>> then you must link OSC.dll with an external pthreads library which
>>>>>>>>> might be static or might be dynamic. If you build OSC.dll usng the
>>>>>>>>> dynamic liblo DLL then instead of OSC.dll linking with pthreads, it is
>>>>>>>>> liblo that must link with pthreads and again that an be the static
>>>>>>>>> pthreads library or the dynamic pthreads library. But we are linking
>>>>>>>>> with the static liblo so it is OSC.dll that must link with pthreads
>>>>>>>>> either statically or dynamically.
>>>>>>>>
>>>>>>>>
>>>>>>>> Ok. Thanks for the clarification. Is this what was happening then in the
>>>>>>>> early days of the msys2 build, i.e, OSC was linked with a static liblo, and

Understood. I was focussed on osc stkops and not tracking the other dlls.

I will try implementing the policy only in the relevant directories,
that might be a simple fix.

Best,
Mike

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


On Thu, Apr 21, 2016 at 3:10 PM, Steven Yi  wrote:
> FYI: commenting out the policy change *does* fix the problem for me,
> at least the sndfile-1 related issue. I do get the osc and stkops not
> loading again, but this is a marked improvement over the previous
> situation.
>
> On Thu, Apr 21, 2016 at 3:08 PM, Steven Yi  wrote:
>> I think the policy change must be the cause of the problem.  I'm
>> guessing the finder for sndfile would have previously found the dll,
>> but at link time, would have used -lsndfile, which would have been
>> affected by the -static flag. That's my guess at least.  As it is now,
>> I'm getting dynamic links for most things. I don't think this policy
>> change is the right answer for this problem.
>>
>> On Thu, Apr 21, 2016 at 3:02 PM, Steven Yi  wrote:
>>> Not at all.  One of the first things I worked on for mingw64 was
>>> getting libsndfile (and its supporting libraries, as this is all
>>> static) to link to libcsound.
>>>
>>> On Thu, Apr 21, 2016 at 1:14 PM, Michael Gogins
>>>  wrote:
>>>> Did we not always link to the dynamic libsndfile?
>>>>
>>>> Best,
>>>> Mike
>>>>
>>>> -----------------------------------------------------
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://michaelgogins.tumblr.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>>
>>>> On Thu, Apr 21, 2016 at 12:23 PM, Steven Yi  wrote:
>>>>> FYI: Dependency walker now shows a link from csound64.dll to libsndfile-1.dll.
>>>>>
>>>>> On Thu, Apr 21, 2016 at 12:10 PM, Steven Yi  wrote:
>>>>>> Hi Michael,
>>>>>>
>>>>>> I just tried a build and things seem to  have gotten worse. Now when I
>>>>>> run Csound I get and error that libsndfile-1.dll can not be found.  I
>>>>>> will try a clean and rebuild now.
>>>>>>
>>>>>> steven
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 21, 2016 at 11:56 AM, Michael Gogins
>>>>>>  wrote:
>>>>>>> More on this, and it's fairly important.
>>>>>>>
>>>>>>> CMake's default behavior in earlier versions was to link with
>>>>>>> libraries found in "standard" locations, even if the full pathname to
>>>>>>> the library was passed to target_link_libraries. Needless to say, this
>>>>>>> is very confusing, because it can easily mean that one sets a full
>>>>>>> pathname to a static library in target_link_libraries and ends up
>>>>>>> linking with the dynamic version of that library anyway because gcc's
>>>>>>> default behavior is to prefer dynamic libraries.
>>>>>>>
>>>>>>> I have added the following code at the head of CMakeLists.txt to fix
>>>>>>> this problem:
>>>>>>>
>>>>>>> # Instruct CMake to use specified pathnames for target_link_library even if
>>>>>>> # another version of the specified library exists in a standard location.
>>>>>>> if(WIN32)
>>>>>>>     cmake_policy(SET CMP0060 NEW)
>>>>>>> endif()
>>>>>>>
>>>>>>> Regards,
>>>>>>> Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----------------------------------------------------
>>>>>>> Michael Gogins
>>>>>>> Irreducible Productions
>>>>>>> http://michaelgogins.tumblr.com
>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Apr 20, 2016 at 3:20 PM, Michael Gogins
>>>>>>>  wrote:
>>>>>>>> I think you are correct, OSC used to link with static liblo or static
>>>>>>>> pthread, but OSC also could have linked with dynamic liblo which in
>>>>>>>> turn was linked with static pthread. In your original ldd printout you
>>>>>>>> can see if the liblo DLL is listed, if not, then both liblo and
>>>>>>>> pthread were statically linked.
>>>>>>>>
>>>>>>>> I believe I have identified and fixed the problem, soon to be booked
>>>>>>>> in, but I'm not happy with this situation. There are other plugins
>>>>>>>> where this might be happening. I will try to fix any that I see.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> -----------------------------------------------------
>>>>>>>> Michael Gogins
>>>>>>>> Irreducible Productions
>>>>>>>> http://michaelgogins.tumblr.com
>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Apr 20, 2016 at 3:02 PM, Rory Walsh  wrote:
>>>>>>>>>> Just to be clear, the pkgbuild thing is not the problem. No matter
>>>>>>>>>> what there will be a dependency on pthreads. The issue is whether
>>>>>>>>>> osc.dll links with pthreads static libraryt or pthreads dll.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This is clear.
>>>>>>>>>
>>>>>>>>>> It's not straightforward. If you build OSC.dll using the static liblo
>>>>>>>>>> then you must link OSC.dll with an external pthreads library which
>>>>>>>>>> might be static or might be dynamic. If you build OSC.dll usng the
>>>>>>>>>> dynamic liblo DLL then instead of OSC.dll linking with pthreads, it is
>>>>>>>>>> liblo that must link with pthreads and again that an be the static
>>>>>>>>>> pthreads library or the dynamic pthreads library. But we are linking
>>>>>>>>>> with the static liblo so it is OSC.dll that must link with pthreads
>>>>>>>>>> either statically or dynamically.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ok. Thanks for the clarification. Is this what was happening then in the
>>>>>>>>> early days of the msys2 build, i.e, OSC was linked with a static liblo, and