Hi All,

I found a new bug with the Windows build I'm considering critical.
The problem goes back to this mailing list thread:

http://csound.1045644.n5.nabble.com/Csnd-dev-libsndfile-and-MSVC-build-td5757593.html

which brings up this note from libsndfile:

Note: On Microsoft Windows, this function does not work if the
application and the libsndfile DLL are linked to different versions of
the Microsoft C runtime DLL.

What I am seeing is that using Csound from Blue, I can not open any
sound files.  For example, in Blue, I get this reported in Csound's
output:

         44100 Hz, 2 channel(s), -1 sample frames

while running the same CSD from commandline I get:

         44100 Hz, 2 channel(s), 7056000 sample frames


I suspect the issue is again one of linking to different C runtime
dlls.  In this case, I have no control over what runtime is linked to
as it is the Java executable that is linked to whatever runtime it
has.  I would expect any Csound API using program to be in peril of
running into this.  We also can't simply just switch the runtime as it
could be that a user uses a program linked to the other runtime.

There is some info that looks useful on sndfile's github site:

https://github.com/erikd/libsndfile

under "Notes for Windows Users".  I am going to start a branch to
experiment with this and will report back any progress.

I'm experimenting but with using the static version of the triplet. The port file for libsndfile  mentions static linking but I'm not quite sure how to get that to work or if anything is necessary beyond the static triplet change.

I've pushed a feature/sndfile-msvc branch up to Git.  Locally, it does
not work but it's as far as I've gotten so far.  What I've done:

- changed the vcpkg install call to use x64-windows-static for triplet
- tried to update places I found where it looks like it should be
updated for static linking

So far, I get as far as trying to generate the VS project but cmake
saying it failed to find sndfile.h.  In my vcpkg folder it is there
though in the vcpkg/packages/libsndfile_x64-windows-static/include
folder.

I'm going to take a break for the day and will resume on this
tomorrow. Stephen, if you have a chance to take a look that'd be
great.


On Wed, Dec 6, 2017 at 6:39 PM, Steven Yi  wrote:
> I'm experimenting but with using the static version of the triplet. The port
> file for libsndfile  mentions static linking but I'm not quite sure how to
> get that to work or if anything is necessary beyond the static triplet
> change.
>
>
> On Wed, Dec 6, 2017, 18:31 Stephen Kyne  wrote:
>>
>> Seems like they're aware of VCPKG so they might have an answer on how to
>> build it for our needs? Maybe raise an issue to find out? We can make build
>> changes if that solves the problem though. It's possible to build a VCPKG
>> package with a static CRT.
>>
>> Stephen
>> ________________________________
>> From: Csound-developers  on behalf of
>> Steven Yi 
>> Sent: 06 December 2017 23:17
>> To: CSOUND-DEV@LISTSERV.HEANET.IE
>> Subject: [Csnd-dev] Windows: Problem again with libsndfile (critical)
>>
>> Hi All,
>>
>> I found a new bug with the Windows build I'm considering critical.
>> The problem goes back to this mailing list thread:
>>
>>
>> http://csound.1045644.n5.nabble.com/Csnd-dev-libsndfile-and-MSVC-build-td5757593.html
>>
>> which brings up this note from libsndfile:
>>
>> Note: On Microsoft Windows, this function does not work if the
>> application and the libsndfile DLL are linked to different versions of
>> the Microsoft C runtime DLL.
>>
>> What I am seeing is that using Csound from Blue, I can not open any
>> sound files.  For example, in Blue, I get this reported in Csound's
>> output:
>>
>>          44100 Hz, 2 channel(s), -1 sample frames
>>
>> while running the same CSD from commandline I get:
>>
>>          44100 Hz, 2 channel(s), 7056000 sample frames
>>
>>
>> I suspect the issue is again one of linking to different C runtime
>> dlls.  In this case, I have no control over what runtime is linked to
>> as it is the Java executable that is linked to whatever runtime it
>> has.  I would expect any Csound API using program to be in peril of
>> running into this.  We also can't simply just switch the runtime as it
>> could be that a user uses a program linked to the other runtime.
>>
>> There is some info that looks useful on sndfile's github site:
>>
>> https://github.com/erikd/libsndfile
>>
>> under "Notes for Windows Users".  I am going to start a branch to
>> experiment with this and will report back any progress.
>>

I did have just a little more time and found that our Cmake file
wasn't written correctly when trying to look for libraries with
multiple names; we also needed to add libsndfile as a possibility as
the static build creates libsndfile.lib while the dynamic one creates
libsndfile-1.lib.  Moving past that, I got the VS project to generate
but then there were linking problems but it had to do with sndfile
dependencies (flac, ogg, vorbis, etc.).

What ended up working was modifying the Cmake files to get things to
look very similar to what we had for the MSYS2 build, which also used
static libsndfile.  I haven't checked exactly but so far it looks the
last changes I did got through a full build. I need to verify that all
of the targets were built amongst other things, but I just tested and
thankfully the change *does* fix the problem from Blue (and I would
imagine other API-using programs).

I'll stop now and continue to review tomorrow (haven't looked outside
of the local build stuff, so no idea what changes are necessary for
installer scripts, etc.) and will merge back into develop once it
looks good.

On Wed, Dec 6, 2017 at 7:17 PM, Steven Yi  wrote:
> I've pushed a feature/sndfile-msvc branch up to Git.  Locally, it does
> not work but it's as far as I've gotten so far.  What I've done:
>
> - changed the vcpkg install call to use x64-windows-static for triplet
> - tried to update places I found where it looks like it should be
> updated for static linking
>
> So far, I get as far as trying to generate the VS project but cmake
> saying it failed to find sndfile.h.  In my vcpkg folder it is there
> though in the vcpkg/packages/libsndfile_x64-windows-static/include
> folder.
>
> I'm going to take a break for the day and will resume on this
> tomorrow. Stephen, if you have a chance to take a look that'd be
> great.
>
>
> On Wed, Dec 6, 2017 at 6:39 PM, Steven Yi  wrote:
>> I'm experimenting but with using the static version of the triplet. The port
>> file for libsndfile  mentions static linking but I'm not quite sure how to
>> get that to work or if anything is necessary beyond the static triplet
>> change.
>>
>>
>> On Wed, Dec 6, 2017, 18:31 Stephen Kyne  wrote:
>>>
>>> Seems like they're aware of VCPKG so they might have an answer on how to
>>> build it for our needs? Maybe raise an issue to find out? We can make build
>>> changes if that solves the problem though. It's possible to build a VCPKG
>>> package with a static CRT.
>>>
>>> Stephen
>>> ________________________________
>>> From: Csound-developers  on behalf of
>>> Steven Yi 
>>> Sent: 06 December 2017 23:17
>>> To: CSOUND-DEV@LISTSERV.HEANET.IE
>>> Subject: [Csnd-dev] Windows: Problem again with libsndfile (critical)
>>>
>>> Hi All,
>>>
>>> I found a new bug with the Windows build I'm considering critical.
>>> The problem goes back to this mailing list thread:
>>>
>>>
>>> http://csound.1045644.n5.nabble.com/Csnd-dev-libsndfile-and-MSVC-build-td5757593.html
>>>
>>> which brings up this note from libsndfile:
>>>
>>> Note: On Microsoft Windows, this function does not work if the
>>> application and the libsndfile DLL are linked to different versions of
>>> the Microsoft C runtime DLL.
>>>
>>> What I am seeing is that using Csound from Blue, I can not open any
>>> sound files.  For example, in Blue, I get this reported in Csound's
>>> output:
>>>
>>>          44100 Hz, 2 channel(s), -1 sample frames
>>>
>>> while running the same CSD from commandline I get:
>>>
>>>          44100 Hz, 2 channel(s), 7056000 sample frames
>>>
>>>
>>> I suspect the issue is again one of linking to different C runtime
>>> dlls.  In this case, I have no control over what runtime is linked to
>>> as it is the Java executable that is linked to whatever runtime it
>>> has.  I would expect any Csound API using program to be in peril of
>>> running into this.  We also can't simply just switch the runtime as it
>>> could be that a user uses a program linked to the other runtime.
>>>
>>> There is some info that looks useful on sndfile's github site:
>>>
>>> https://github.com/erikd/libsndfile
>>>
>>> under "Notes for Windows Users".  I am going to start a branch to
>>> experiment with this and will report back any progress.
>>>

Just a small update: I'm working on fixing up dependencies now:

* fltk was left off the list and I've added that back in here locally
* The link for manually downloading hdf5 was out of date and always
failing (a new version was published at the FTP and the old link
removed).  I see hdf5 in vcpkg, so I am testing that out now.





On Wed, Dec 6, 2017 at 8:06 PM, Steven Yi  wrote:
> I did have just a little more time and found that our Cmake file
> wasn't written correctly when trying to look for libraries with
> multiple names; we also needed to add libsndfile as a possibility as
> the static build creates libsndfile.lib while the dynamic one creates
> libsndfile-1.lib.  Moving past that, I got the VS project to generate
> but then there were linking problems but it had to do with sndfile
> dependencies (flac, ogg, vorbis, etc.).
>
> What ended up working was modifying the Cmake files to get things to
> look very similar to what we had for the MSYS2 build, which also used
> static libsndfile.  I haven't checked exactly but so far it looks the
> last changes I did got through a full build. I need to verify that all
> of the targets were built amongst other things, but I just tested and
> thankfully the change *does* fix the problem from Blue (and I would
> imagine other API-using programs).
>
> I'll stop now and continue to review tomorrow (haven't looked outside
> of the local build stuff, so no idea what changes are necessary for
> installer scripts, etc.) and will merge back into develop once it
> looks good.
>
> On Wed, Dec 6, 2017 at 7:17 PM, Steven Yi  wrote:
>> I've pushed a feature/sndfile-msvc branch up to Git.  Locally, it does
>> not work but it's as far as I've gotten so far.  What I've done:
>>
>> - changed the vcpkg install call to use x64-windows-static for triplet
>> - tried to update places I found where it looks like it should be
>> updated for static linking
>>
>> So far, I get as far as trying to generate the VS project but cmake
>> saying it failed to find sndfile.h.  In my vcpkg folder it is there
>> though in the vcpkg/packages/libsndfile_x64-windows-static/include
>> folder.
>>
>> I'm going to take a break for the day and will resume on this
>> tomorrow. Stephen, if you have a chance to take a look that'd be
>> great.
>>
>>
>> On Wed, Dec 6, 2017 at 6:39 PM, Steven Yi  wrote:
>>> I'm experimenting but with using the static version of the triplet. The port
>>> file for libsndfile  mentions static linking but I'm not quite sure how to
>>> get that to work or if anything is necessary beyond the static triplet
>>> change.
>>>
>>>
>>> On Wed, Dec 6, 2017, 18:31 Stephen Kyne  wrote:
>>>>
>>>> Seems like they're aware of VCPKG so they might have an answer on how to
>>>> build it for our needs? Maybe raise an issue to find out? We can make build
>>>> changes if that solves the problem though. It's possible to build a VCPKG
>>>> package with a static CRT.
>>>>
>>>> Stephen
>>>> ________________________________
>>>> From: Csound-developers  on behalf of
>>>> Steven Yi 
>>>> Sent: 06 December 2017 23:17
>>>> To: CSOUND-DEV@LISTSERV.HEANET.IE
>>>> Subject: [Csnd-dev] Windows: Problem again with libsndfile (critical)
>>>>
>>>> Hi All,
>>>>
>>>> I found a new bug with the Windows build I'm considering critical.
>>>> The problem goes back to this mailing list thread:
>>>>
>>>>
>>>> http://csound.1045644.n5.nabble.com/Csnd-dev-libsndfile-and-MSVC-build-td5757593.html
>>>>
>>>> which brings up this note from libsndfile:
>>>>
>>>> Note: On Microsoft Windows, this function does not work if the
>>>> application and the libsndfile DLL are linked to different versions of
>>>> the Microsoft C runtime DLL.
>>>>
>>>> What I am seeing is that using Csound from Blue, I can not open any
>>>> sound files.  For example, in Blue, I get this reported in Csound's
>>>> output:
>>>>
>>>>          44100 Hz, 2 channel(s), -1 sample frames
>>>>
>>>> while running the same CSD from commandline I get:
>>>>
>>>>          44100 Hz, 2 channel(s), 7056000 sample frames
>>>>
>>>>
>>>> I suspect the issue is again one of linking to different C runtime
>>>> dlls.  In this case, I have no control over what runtime is linked to
>>>> as it is the Java executable that is linked to whatever runtime it
>>>> has.  I would expect any Csound API using program to be in peril of
>>>> running into this.  We also can't simply just switch the runtime as it
>>>> could be that a user uses a program linked to the other runtime.
>>>>
>>>> There is some info that looks useful on sndfile's github site:
>>>>
>>>> https://github.com/erikd/libsndfile
>>>>
>>>> under "Notes for Windows Users".  I am going to start a branch to
>>>> experiment with this and will report back any progress.
>>>>

FLTK was there but I had left it out when I went to switch to static.
I spent a while just now trying to get HDF5 to work but it's a mess.

1. If we try to use the one from VCPKG, it gives some kind of message
about needing to run an MSI separately
2. The current URL for 1.8.19 no longer works
3. The URL for 1.8.20 doesn't work unless you modify the script to use TLS 1.2
4. Even then, the msiexec call seems to fail.

The scripts are sort of awkardly setup at the moment to hardcode the
installation path of HDF5 and not do a search.

Also, the downloadDependencies.ps1 script takes an awful long time.
The way it is setup, it re-expands all downloaded zips, meaning
minutes are lost wasted unpacking things like VST SDK that are already
unpacked.  That's something that should be optimized at some point.

I'm going to take a break from HDF5 and look at what else is left.

On Thu, Dec 7, 2017 at 2:01 PM, Stephen Kyne  wrote:
> We were using the HDF5 from VCPKG but Michael ended up switching it for some
> reason. I can't remember now.
> FLTK should have been there, strange.
>
> Stephen
> ________________________________
> From: Csound-developers  on behalf of Steven
> Yi 
> Sent: 07 December 2017 16:17
> To: CSOUND-DEV@LISTSERV.HEANET.IE
> Subject: Re: [Csnd-dev] Windows: Problem again with libsndfile (critical)
>
> Just a small update: I'm working on fixing up dependencies now:
>
> * fltk was left off the list and I've added that back in here locally
> * The link for manually downloading hdf5 was out of date and always
> failing (a new version was published at the FTP and the old link
> removed).  I see hdf5 in vcpkg, so I am testing that out now.
>
>
>
>
>
> On Wed, Dec 6, 2017 at 8:06 PM, Steven Yi  wrote:
>> I did have just a little more time and found that our Cmake file
>> wasn't written correctly when trying to look for libraries with
>> multiple names; we also needed to add libsndfile as a possibility as
>> the static build creates libsndfile.lib while the dynamic one creates
>> libsndfile-1.lib.  Moving past that, I got the VS project to generate
>> but then there were linking problems but it had to do with sndfile
>> dependencies (flac, ogg, vorbis, etc.).
>>
>> What ended up working was modifying the Cmake files to get things to
>> look very similar to what we had for the MSYS2 build, which also used
>> static libsndfile.  I haven't checked exactly but so far it looks the
>> last changes I did got through a full build. I need to verify that all
>> of the targets were built amongst other things, but I just tested and
>> thankfully the change *does* fix the problem from Blue (and I would
>> imagine other API-using programs).
>>
>> I'll stop now and continue to review tomorrow (haven't looked outside
>> of the local build stuff, so no idea what changes are necessary for
>> installer scripts, etc.) and will merge back into develop once it
>> looks good.
>>
>> On Wed, Dec 6, 2017 at 7:17 PM, Steven Yi  wrote:
>>> I've pushed a feature/sndfile-msvc branch up to Git.  Locally, it does
>>> not work but it's as far as I've gotten so far.  What I've done:
>>>
>>> - changed the vcpkg install call to use x64-windows-static for triplet
>>> - tried to update places I found where it looks like it should be
>>> updated for static linking
>>>
>>> So far, I get as far as trying to generate the VS project but cmake
>>> saying it failed to find sndfile.h.  In my vcpkg folder it is there
>>> though in the vcpkg/packages/libsndfile_x64-windows-static/include
>>> folder.
>>>
>>> I'm going to take a break for the day and will resume on this
>>> tomorrow. Stephen, if you have a chance to take a look that'd be
>>> great.
>>>
>>>
>>> On Wed, Dec 6, 2017 at 6:39 PM, Steven Yi  wrote:
>>>> I'm experimenting but with using the static version of the triplet. The
>>>> port
>>>> file for libsndfile  mentions static linking but I'm not quite sure how
>>>> to
>>>> get that to work or if anything is necessary beyond the static triplet
>>>> change.
>>>>
>>>>
>>>> On Wed, Dec 6, 2017, 18:31 Stephen Kyne  wrote:
>>>>>
>>>>> Seems like they're aware of VCPKG so they might have an answer on how
>>>>> to
>>>>> build it for our needs? Maybe raise an issue to find out? We can make
>>>>> build
>>>>> changes if that solves the problem though. It's possible to build a
>>>>> VCPKG
>>>>> package with a static CRT.
>>>>>
>>>>> Stephen
>>>>> ________________________________
>>>>> From: Csound-developers  on behalf of
>>>>> Steven Yi 
>>>>> Sent: 06 December 2017 23:17
>>>>> To: CSOUND-DEV@LISTSERV.HEANET.IE
>>>>> Subject: [Csnd-dev] Windows: Problem again with libsndfile (critical)
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I found a new bug with the Windows build I'm considering critical.
>>>>> The problem goes back to this mailing list thread:
>>>>>
>>>>>
>>>>>
>>>>> http://csound.1045644.n5.nabble.com/Csnd-dev-libsndfile-and-MSVC-build-td5757593.html
>>>>>
>>>>> which brings up this note from libsndfile:
>>>>>
>>>>> Note: On Microsoft Windows, this function does not work if the
>>>>> application and the libsndfile DLL are linked to different versions of
>>>>> the Microsoft C runtime DLL.
>>>>>
>>>>> What I am seeing is that using Csound from Blue, I can not open any
>>>>> sound files.  For example, in Blue, I get this reported in Csound's
>>>>> output:
>>>>>
>>>>>          44100 Hz, 2 channel(s), -1 sample frames
>>>>>
>>>>> while running the same CSD from commandline I get:
>>>>>
>>>>>          44100 Hz, 2 channel(s), 7056000 sample frames
>>>>>
>>>>>
>>>>> I suspect the issue is again one of linking to different C runtime
>>>>> dlls.  In this case, I have no control over what runtime is linked to
>>>>> as it is the Java executable that is linked to whatever runtime it
>>>>> has.  I would expect any Csound API using program to be in peril of
>>>>> running into this.  We also can't simply just switch the runtime as it
>>>>> could be that a user uses a program linked to the other runtime.
>>>>>
>>>>> There is some info that looks useful on sndfile's github site:
>>>>>
>>>>> https://github.com/erikd/libsndfile
>>>>>
>>>>> under "Notes for Windows Users".  I am going to start a branch to
>>>>> experiment with this and will report back any progress.
>>>>>

Update: I've merged the feature/sndfile-msvc branch back into develop.
The Appveyor installer is being built using static linking for
libsndfile, fltk, and other VCPKG deps.  I installed the installer
that was built and did some basic tests that worked.

One thing I did find: the installer does not include CsoundQt.  This
looks like a problem introduced prior to the work in the branch. What
I'm seeing is that the build is building some kind of CsoundQt with
"deb" or "dbg" in the name (can't remember off top of my head), but
the installer seems to look for "CsoundQt-d-cs6.exe".  It seems to me
that the building part should be corrected rather than the installer,
but I don't know what is supposed to be done there (Michael: could you
take a look?)


On Thu, Dec 7, 2017 at 2:53 PM, Steven Yi  wrote:
> FLTK was there but I had left it out when I went to switch to static.
> I spent a while just now trying to get HDF5 to work but it's a mess.
>
> 1. If we try to use the one from VCPKG, it gives some kind of message
> about needing to run an MSI separately
> 2. The current URL for 1.8.19 no longer works
> 3. The URL for 1.8.20 doesn't work unless you modify the script to use TLS 1.2
> 4. Even then, the msiexec call seems to fail.
>
> The scripts are sort of awkardly setup at the moment to hardcode the
> installation path of HDF5 and not do a search.
>
> Also, the downloadDependencies.ps1 script takes an awful long time.
> The way it is setup, it re-expands all downloaded zips, meaning
> minutes are lost wasted unpacking things like VST SDK that are already
> unpacked.  That's something that should be optimized at some point.
>
> I'm going to take a break from HDF5 and look at what else is left.
>
> On Thu, Dec 7, 2017 at 2:01 PM, Stephen Kyne  wrote:
>> We were using the HDF5 from VCPKG but Michael ended up switching it for some
>> reason. I can't remember now.
>> FLTK should have been there, strange.
>>
>> Stephen
>> ________________________________
>> From: Csound-developers  on behalf of Steven
>> Yi 
>> Sent: 07 December 2017 16:17
>> To: CSOUND-DEV@LISTSERV.HEANET.IE
>> Subject: Re: [Csnd-dev] Windows: Problem again with libsndfile (critical)
>>
>> Just a small update: I'm working on fixing up dependencies now:
>>
>> * fltk was left off the list and I've added that back in here locally
>> * The link for manually downloading hdf5 was out of date and always
>> failing (a new version was published at the FTP and the old link
>> removed).  I see hdf5 in vcpkg, so I am testing that out now.
>>
>>
>>
>>
>>
>> On Wed, Dec 6, 2017 at 8:06 PM, Steven Yi  wrote:
>>> I did have just a little more time and found that our Cmake file
>>> wasn't written correctly when trying to look for libraries with
>>> multiple names; we also needed to add libsndfile as a possibility as
>>> the static build creates libsndfile.lib while the dynamic one creates
>>> libsndfile-1.lib.  Moving past that, I got the VS project to generate
>>> but then there were linking problems but it had to do with sndfile
>>> dependencies (flac, ogg, vorbis, etc.).
>>>
>>> What ended up working was modifying the Cmake files to get things to
>>> look very similar to what we had for the MSYS2 build, which also used
>>> static libsndfile.  I haven't checked exactly but so far it looks the
>>> last changes I did got through a full build. I need to verify that all
>>> of the targets were built amongst other things, but I just tested and
>>> thankfully the change *does* fix the problem from Blue (and I would
>>> imagine other API-using programs).
>>>
>>> I'll stop now and continue to review tomorrow (haven't looked outside
>>> of the local build stuff, so no idea what changes are necessary for
>>> installer scripts, etc.) and will merge back into develop once it
>>> looks good.
>>>
>>> On Wed, Dec 6, 2017 at 7:17 PM, Steven Yi  wrote:
>>>> I've pushed a feature/sndfile-msvc branch up to Git.  Locally, it does
>>>> not work but it's as far as I've gotten so far.  What I've done:
>>>>
>>>> - changed the vcpkg install call to use x64-windows-static for triplet
>>>> - tried to update places I found where it looks like it should be
>>>> updated for static linking
>>>>
>>>> So far, I get as far as trying to generate the VS project but cmake
>>>> saying it failed to find sndfile.h.  In my vcpkg folder it is there
>>>> though in the vcpkg/packages/libsndfile_x64-windows-static/include
>>>> folder.
>>>>
>>>> I'm going to take a break for the day and will resume on this
>>>> tomorrow. Stephen, if you have a chance to take a look that'd be
>>>> great.
>>>>
>>>>
>>>> On Wed, Dec 6, 2017 at 6:39 PM, Steven Yi  wrote:
>>>>> I'm experimenting but with using the static version of the triplet. The
>>>>> port
>>>>> file for libsndfile  mentions static linking but I'm not quite sure how
>>>>> to
>>>>> get that to work or if anything is necessary beyond the static triplet
>>>>> change.
>>>>>
>>>>>
>>>>> On Wed, Dec 6, 2017, 18:31 Stephen Kyne  wrote:
>>>>>>
>>>>>> Seems like they're aware of VCPKG so they might have an answer on how
>>>>>> to
>>>>>> build it for our needs? Maybe raise an issue to find out? We can make
>>>>>> build
>>>>>> changes if that solves the problem though. It's possible to build a
>>>>>> VCPKG
>>>>>> package with a static CRT.
>>>>>>
>>>>>> Stephen
>>>>>> ________________________________
>>>>>> From: Csound-developers  on behalf of
>>>>>> Steven Yi 
>>>>>> Sent: 06 December 2017 23:17
>>>>>> To: CSOUND-DEV@LISTSERV.HEANET.IE
>>>>>> Subject: [Csnd-dev] Windows: Problem again with libsndfile (critical)
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I found a new bug with the Windows build I'm considering critical.
>>>>>> The problem goes back to this mailing list thread:
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://csound.1045644.n5.nabble.com/Csnd-dev-libsndfile-and-MSVC-build-td5757593.html
>>>>>>
>>>>>> which brings up this note from libsndfile:
>>>>>>
>>>>>> Note: On Microsoft Windows, this function does not work if the
>>>>>> application and the libsndfile DLL are linked to different versions of
>>>>>> the Microsoft C runtime DLL.
>>>>>>
>>>>>> What I am seeing is that using Csound from Blue, I can not open any
>>>>>> sound files.  For example, in Blue, I get this reported in Csound's
>>>>>> output:
>>>>>>
>>>>>>          44100 Hz, 2 channel(s), -1 sample frames
>>>>>>
>>>>>> while running the same CSD from commandline I get:
>>>>>>
>>>>>>          44100 Hz, 2 channel(s), 7056000 sample frames
>>>>>>
>>>>>>
>>>>>> I suspect the issue is again one of linking to different C runtime
>>>>>> dlls.  In this case, I have no control over what runtime is linked to
>>>>>> as it is the Java executable that is linked to whatever runtime it
>>>>>> has.  I would expect any Csound API using program to be in peril of
>>>>>> running into this.  We also can't simply just switch the runtime as it
>>>>>> could be that a user uses a program linked to the other runtime.
>>>>>>
>>>>>> There is some info that looks useful on sndfile's github site:
>>>>>>
>>>>>> https://github.com/erikd/libsndfile
>>>>>>
>>>>>> under "Notes for Windows Users".  I am going to start a branch to
>>>>>> experiment with this and will report back any progress.
>>>>>>

The AppVeyor build log shows:

..\..\..\include\csound.hpp(436): warning C4244: 'return': conversion
from 'int64_t' to 'long', possible loss of data
..\..\..\interfaces\csPerfThread.cpp(29): fatal error C1083: Cannot
open include file: 'sndfile.h': No such file or directory

Best,
Mike

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


On Thu, Dec 7, 2017 at 10:05 PM, Steven Yi  wrote:
> Update: I've merged the feature/sndfile-msvc branch back into develop.
> The Appveyor installer is being built using static linking for
> libsndfile, fltk, and other VCPKG deps.  I installed the installer
> that was built and did some basic tests that worked.
>
> One thing I did find: the installer does not include CsoundQt.  This
> looks like a problem introduced prior to the work in the branch. What
> I'm seeing is that the build is building some kind of CsoundQt with
> "deb" or "dbg" in the name (can't remember off top of my head), but
> the installer seems to look for "CsoundQt-d-cs6.exe".  It seems to me
> that the building part should be corrected rather than the installer,
> but I don't know what is supposed to be done there (Michael: could you
> take a look?)
>
>
> On Thu, Dec 7, 2017 at 2:53 PM, Steven Yi  wrote:
>> FLTK was there but I had left it out when I went to switch to static.
>> I spent a while just now trying to get HDF5 to work but it's a mess.
>>
>> 1. If we try to use the one from VCPKG, it gives some kind of message
>> about needing to run an MSI separately
>> 2. The current URL for 1.8.19 no longer works
>> 3. The URL for 1.8.20 doesn't work unless you modify the script to use TLS 1.2
>> 4. Even then, the msiexec call seems to fail.
>>
>> The scripts are sort of awkardly setup at the moment to hardcode the
>> installation path of HDF5 and not do a search.
>>
>> Also, the downloadDependencies.ps1 script takes an awful long time.
>> The way it is setup, it re-expands all downloaded zips, meaning
>> minutes are lost wasted unpacking things like VST SDK that are already
>> unpacked.  That's something that should be optimized at some point.
>>
>> I'm going to take a break from HDF5 and look at what else is left.
>>
>> On Thu, Dec 7, 2017 at 2:01 PM, Stephen Kyne  wrote:
>>> We were using the HDF5 from VCPKG but Michael ended up switching it for some
>>> reason. I can't remember now.
>>> FLTK should have been there, strange.
>>>
>>> Stephen
>>> ________________________________
>>> From: Csound-developers  on behalf of Steven
>>> Yi 
>>> Sent: 07 December 2017 16:17
>>> To: CSOUND-DEV@LISTSERV.HEANET.IE
>>> Subject: Re: [Csnd-dev] Windows: Problem again with libsndfile (critical)
>>>
>>> Just a small update: I'm working on fixing up dependencies now:
>>>
>>> * fltk was left off the list and I've added that back in here locally
>>> * The link for manually downloading hdf5 was out of date and always
>>> failing (a new version was published at the FTP and the old link
>>> removed).  I see hdf5 in vcpkg, so I am testing that out now.
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Dec 6, 2017 at 8:06 PM, Steven Yi  wrote:
>>>> I did have just a little more time and found that our Cmake file
>>>> wasn't written correctly when trying to look for libraries with
>>>> multiple names; we also needed to add libsndfile as a possibility as
>>>> the static build creates libsndfile.lib while the dynamic one creates
>>>> libsndfile-1.lib.  Moving past that, I got the VS project to generate
>>>> but then there were linking problems but it had to do with sndfile
>>>> dependencies (flac, ogg, vorbis, etc.).
>>>>
>>>> What ended up working was modifying the Cmake files to get things to
>>>> look very similar to what we had for the MSYS2 build, which also used
>>>> static libsndfile.  I haven't checked exactly but so far it looks the
>>>> last changes I did got through a full build. I need to verify that all
>>>> of the targets were built amongst other things, but I just tested and
>>>> thankfully the change *does* fix the problem from Blue (and I would
>>>> imagine other API-using programs).
>>>>
>>>> I'll stop now and continue to review tomorrow (haven't looked outside
>>>> of the local build stuff, so no idea what changes are necessary for
>>>> installer scripts, etc.) and will merge back into develop once it
>>>> looks good.
>>>>
>>>> On Wed, Dec 6, 2017 at 7:17 PM, Steven Yi  wrote:
>>>>> I've pushed a feature/sndfile-msvc branch up to Git.  Locally, it does
>>>>> not work but it's as far as I've gotten so far.  What I've done:
>>>>>
>>>>> - changed the vcpkg install call to use x64-windows-static for triplet
>>>>> - tried to update places I found where it looks like it should be
>>>>> updated for static linking
>>>>>
>>>>> So far, I get as far as trying to generate the VS project but cmake
>>>>> saying it failed to find sndfile.h.  In my vcpkg folder it is there
>>>>> though in the vcpkg/packages/libsndfile_x64-windows-static/include
>>>>> folder.
>>>>>
>>>>> I'm going to take a break for the day and will resume on this
>>>>> tomorrow. Stephen, if you have a chance to take a look that'd be
>>>>> great.
>>>>>
>>>>>
>>>>> On Wed, Dec 6, 2017 at 6:39 PM, Steven Yi  wrote:
>>>>>> I'm experimenting but with using the static version of the triplet. The
>>>>>> port
>>>>>> file for libsndfile  mentions static linking but I'm not quite sure how
>>>>>> to
>>>>>> get that to work or if anything is necessary beyond the static triplet
>>>>>> change.
>>>>>>
>>>>>>
>>>>>> On Wed, Dec 6, 2017, 18:31 Stephen Kyne  wrote:
>>>>>>>
>>>>>>> Seems like they're aware of VCPKG so they might have an answer on how
>>>>>>> to
>>>>>>> build it for our needs? Maybe raise an issue to find out? We can make
>>>>>>> build
>>>>>>> changes if that solves the problem though. It's possible to build a
>>>>>>> VCPKG
>>>>>>> package with a static CRT.
>>>>>>>
>>>>>>> Stephen
>>>>>>> ________________________________
>>>>>>> From: Csound-developers  on behalf of
>>>>>>> Steven Yi 
>>>>>>> Sent: 06 December 2017 23:17
>>>>>>> To: CSOUND-DEV@LISTSERV.HEANET.IE
>>>>>>> Subject: [Csnd-dev] Windows: Problem again with libsndfile (critical)
>>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I found a new bug with the Windows build I'm considering critical.
>>>>>>> The problem goes back to this mailing list thread:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://csound.1045644.n5.nabble.com/Csnd-dev-libsndfile-and-MSVC-build-td5757593.html
>>>>>>>
>>>>>>> which brings up this note from libsndfile:
>>>>>>>
>>>>>>> Note: On Microsoft Windows, this function does not work if the
>>>>>>> application and the libsndfile DLL are linked to different versions of
>>>>>>> the Microsoft C runtime DLL.
>>>>>>>
>>>>>>> What I am seeing is that using Csound from Blue, I can not open any
>>>>>>> sound files.  For example, in Blue, I get this reported in Csound's
>>>>>>> output:
>>>>>>>
>>>>>>>          44100 Hz, 2 channel(s), -1 sample frames
>>>>>>>
>>>>>>> while running the same CSD from commandline I get:
>>>>>>>
>>>>>>>          44100 Hz, 2 channel(s), 7056000 sample frames
>>>>>>>
>>>>>>>
>>>>>>> I suspect the issue is again one of linking to different C runtime
>>>>>>> dlls.  In this case, I have no control over what runtime is linked to
>>>>>>> as it is the Java executable that is linked to whatever runtime it
>>>>>>> has.  I would expect any Csound API using program to be in peril of
>>>>>>> running into this.  We also can't simply just switch the runtime as it
>>>>>>> could be that a user uses a program linked to the other runtime.
>>>>>>>
>>>>>>> There is some info that looks useful on sndfile's github site:
>>>>>>>
>>>>>>> https://github.com/erikd/libsndfile
>>>>>>>
>>>>>>> under "Notes for Windows Users".  I am going to start a branch to
>>>>>>> experiment with this and will report back any progress.
>>>>>>>

Thanks, looks like build-csoundqt.bat needed an update for paths and
different libsndfile.lib (instead of libsndfile-1.lib). I pushed a
change there and will await to see what happens on AppVeyor.

If that works, that should be it to have the installer build working
with statically linked deps (and fix the sndfile issue).  There's a
couple of open loops for the release, but I will start a separate
email for that.

On Fri, Dec 8, 2017 at 7:34 AM, Michael Gogins  wrote:
> The AppVeyor build log shows:
>
> ..\..\..\include\csound.hpp(436): warning C4244: 'return': conversion
> from 'int64_t' to 'long', possible loss of data
> ..\..\..\interfaces\csPerfThread.cpp(29): fatal error C1083: Cannot
> open include file: 'sndfile.h': No such file or directory
>
> Best,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Thu, Dec 7, 2017 at 10:05 PM, Steven Yi  wrote:
>> Update: I've merged the feature/sndfile-msvc branch back into develop.
>> The Appveyor installer is being built using static linking for
>> libsndfile, fltk, and other VCPKG deps.  I installed the installer
>> that was built and did some basic tests that worked.
>>
>> One thing I did find: the installer does not include CsoundQt.  This
>> looks like a problem introduced prior to the work in the branch. What
>> I'm seeing is that the build is building some kind of CsoundQt with
>> "deb" or "dbg" in the name (can't remember off top of my head), but
>> the installer seems to look for "CsoundQt-d-cs6.exe".  It seems to me
>> that the building part should be corrected rather than the installer,
>> but I don't know what is supposed to be done there (Michael: could you
>> take a look?)
>>
>>
>> On Thu, Dec 7, 2017 at 2:53 PM, Steven Yi  wrote:
>>> FLTK was there but I had left it out when I went to switch to static.
>>> I spent a while just now trying to get HDF5 to work but it's a mess.
>>>
>>> 1. If we try to use the one from VCPKG, it gives some kind of message
>>> about needing to run an MSI separately
>>> 2. The current URL for 1.8.19 no longer works
>>> 3. The URL for 1.8.20 doesn't work unless you modify the script to use TLS 1.2
>>> 4. Even then, the msiexec call seems to fail.
>>>
>>> The scripts are sort of awkardly setup at the moment to hardcode the
>>> installation path of HDF5 and not do a search.
>>>
>>> Also, the downloadDependencies.ps1 script takes an awful long time.
>>> The way it is setup, it re-expands all downloaded zips, meaning
>>> minutes are lost wasted unpacking things like VST SDK that are already
>>> unpacked.  That's something that should be optimized at some point.
>>>
>>> I'm going to take a break from HDF5 and look at what else is left.
>>>
>>> On Thu, Dec 7, 2017 at 2:01 PM, Stephen Kyne  wrote:
>>>> We were using the HDF5 from VCPKG but Michael ended up switching it for some
>>>> reason. I can't remember now.
>>>> FLTK should have been there, strange.
>>>>
>>>> Stephen
>>>> ________________________________
>>>> From: Csound-developers  on behalf of Steven
>>>> Yi 
>>>> Sent: 07 December 2017 16:17
>>>> To: CSOUND-DEV@LISTSERV.HEANET.IE
>>>> Subject: Re: [Csnd-dev] Windows: Problem again with libsndfile (critical)
>>>>
>>>> Just a small update: I'm working on fixing up dependencies now:
>>>>
>>>> * fltk was left off the list and I've added that back in here locally
>>>> * The link for manually downloading hdf5 was out of date and always
>>>> failing (a new version was published at the FTP and the old link
>>>> removed).  I see hdf5 in vcpkg, so I am testing that out now.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Dec 6, 2017 at 8:06 PM, Steven Yi  wrote:
>>>>> I did have just a little more time and found that our Cmake file
>>>>> wasn't written correctly when trying to look for libraries with
>>>>> multiple names; we also needed to add libsndfile as a possibility as
>>>>> the static build creates libsndfile.lib while the dynamic one creates
>>>>> libsndfile-1.lib.  Moving past that, I got the VS project to generate
>>>>> but then there were linking problems but it had to do with sndfile
>>>>> dependencies (flac, ogg, vorbis, etc.).
>>>>>
>>>>> What ended up working was modifying the Cmake files to get things to
>>>>> look very similar to what we had for the MSYS2 build, which also used
>>>>> static libsndfile.  I haven't checked exactly but so far it looks the
>>>>> last changes I did got through a full build. I need to verify that all
>>>>> of the targets were built amongst other things, but I just tested and
>>>>> thankfully the change *does* fix the problem from Blue (and I would
>>>>> imagine other API-using programs).
>>>>>
>>>>> I'll stop now and continue to review tomorrow (haven't looked outside
>>>>> of the local build stuff, so no idea what changes are necessary for
>>>>> installer scripts, etc.) and will merge back into develop once it
>>>>> looks good.
>>>>>
>>>>> On Wed, Dec 6, 2017 at 7:17 PM, Steven Yi  wrote:
>>>>>> I've pushed a feature/sndfile-msvc branch up to Git.  Locally, it does
>>>>>> not work but it's as far as I've gotten so far.  What I've done:
>>>>>>
>>>>>> - changed the vcpkg install call to use x64-windows-static for triplet
>>>>>> - tried to update places I found where it looks like it should be
>>>>>> updated for static linking
>>>>>>
>>>>>> So far, I get as far as trying to generate the VS project but cmake
>>>>>> saying it failed to find sndfile.h.  In my vcpkg folder it is there
>>>>>> though in the vcpkg/packages/libsndfile_x64-windows-static/include
>>>>>> folder.
>>>>>>
>>>>>> I'm going to take a break for the day and will resume on this
>>>>>> tomorrow. Stephen, if you have a chance to take a look that'd be
>>>>>> great.
>>>>>>
>>>>>>
>>>>>> On Wed, Dec 6, 2017 at 6:39 PM, Steven Yi  wrote:
>>>>>>> I'm experimenting but with using the static version of the triplet. The
>>>>>>> port
>>>>>>> file for libsndfile  mentions static linking but I'm not quite sure how
>>>>>>> to
>>>>>>> get that to work or if anything is necessary beyond the static triplet
>>>>>>> change.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Dec 6, 2017, 18:31 Stephen Kyne  wrote:
>>>>>>>>
>>>>>>>> Seems like they're aware of VCPKG so they might have an answer on how
>>>>>>>> to
>>>>>>>> build it for our needs? Maybe raise an issue to find out? We can make
>>>>>>>> build
>>>>>>>> changes if that solves the problem though. It's possible to build a
>>>>>>>> VCPKG
>>>>>>>> package with a static CRT.
>>>>>>>>
>>>>>>>> Stephen
>>>>>>>> ________________________________
>>>>>>>> From: Csound-developers  on behalf of
>>>>>>>> Steven Yi 
>>>>>>>> Sent: 06 December 2017 23:17
>>>>>>>> To: CSOUND-DEV@LISTSERV.HEANET.IE
>>>>>>>> Subject: [Csnd-dev] Windows: Problem again with libsndfile (critical)
>>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> I found a new bug with the Windows build I'm considering critical.
>>>>>>>> The problem goes back to this mailing list thread:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://csound.1045644.n5.nabble.com/Csnd-dev-libsndfile-and-MSVC-build-td5757593.html
>>>>>>>>
>>>>>>>> which brings up this note from libsndfile:
>>>>>>>>
>>>>>>>> Note: On Microsoft Windows, this function does not work if the
>>>>>>>> application and the libsndfile DLL are linked to different versions of
>>>>>>>> the Microsoft C runtime DLL.
>>>>>>>>
>>>>>>>> What I am seeing is that using Csound from Blue, I can not open any
>>>>>>>> sound files.  For example, in Blue, I get this reported in Csound's
>>>>>>>> output:
>>>>>>>>
>>>>>>>>          44100 Hz, 2 channel(s), -1 sample frames
>>>>>>>>
>>>>>>>> while running the same CSD from commandline I get:
>>>>>>>>
>>>>>>>>          44100 Hz, 2 channel(s), 7056000 sample frames
>>>>>>>>
>>>>>>>>
>>>>>>>> I suspect the issue is again one of linking to different C runtime
>>>>>>>> dlls.  In this case, I have no control over what runtime is linked to
>>>>>>>> as it is the Java executable that is linked to whatever runtime it
>>>>>>>> has.  I would expect any Csound API using program to be in peril of
>>>>>>>> running into this.  We also can't simply just switch the runtime as it
>>>>>>>> could be that a user uses a program linked to the other runtime.
>>>>>>>>
>>>>>>>> There is some info that looks useful on sndfile's github site:
>>>>>>>>
>>>>>>>> https://github.com/erikd/libsndfile
>>>>>>>>
>>>>>>>> under "Notes for Windows Users".  I am going to start a branch to
>>>>>>>> experiment with this and will report back any progress.
>>>>>>>>