Hey Steven,

With the VCPKG version of libsndfile, it will download the source and build locally so it will build with the same CRT version as being built with Csound. Which will most likely be the 2017 version. From what you described, the two were using different versions of the runtime.

https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL.2C_MSVCP.2A.DLL_and_CRTDLL.DLL 

That link mentions that msvcrt.dll is the old version but newer versions use vcruntimeX.dll. 140 is 2015, 150 is 2017 afaik.

So the end user only needs the 2017 runtime distributable then and everything should work fine I guess!

Stephen

---

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Steven Yi <stevenyi@GMAIL.COM>
Sent: 22 August 2017 21:28
To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: Re: [Csnd-dev] libsndfile and MSVC build

 

Hi Stephen,

I don't know much about differences between vcruntime140.dll and msvcrt.dll, but it seems if we can get away without using vcruntime140.dll altogether, that'd be better for covering more Windows installations, no?  (Or, I'm misunderstanding something altogether about these two libs...)

steven

On Sat, Aug 19, 2017 at 7:44 AM, Stephen Kyne <stevek@outlook.ie> wrote:

Hi Steven,

I just saw that libsndfile is actually in vcpkg. So we could just build it from source this way and probably get around this issue. I'll make the change and see how it goes.

Thanks,

Stephen

---

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Steven Yi <stevenyi@GMAIL.COM>
Sent: 18 August 2017 19:44
To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: [Csnd-dev] libsndfile and MSVC build

 

Hi All,

I've been tracing through the file issue I reported regarding the
fairlight.csd example.  I was stepping through code with Visual
Studio's debugger as well as with XCode's. The variables and code
paths were matching until getting to envvar.c:1098. After this, p->sf
was NULL in VS but it was populated with values on XCode.  In looking
around, I found this comment on libsndfile's site
(http://www.mega-nerd.com/libsndfile/api.html#open_fd):

The libsndfile API - Mega Nerd www.mega-nerd.com Libsndfile is a library designed to allow the reading and writing of many different sampled sound file formats (such as MS Windows WAV and the Apple/SGI AIFF format ...

File Descriptor Open

      SNDFILE*  sf_open_fd (int fd, int mode, SF_INFO *sfinfo, int close_desc) ;

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.

Using dependency walker, I saw that libsndfile linked to msvcrt.dll,
but csound was linking to vcruntime140.dll.

Now, I'm not sure this is it, but seems like a good lead.  I've tried
adding the use of /MTd and /MT when compiling:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 050307cd7..dbe88c565 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -20,6 +20,18 @@ set(CMAKE_CXX_FLAGS_RELEASE "-O3 ")
 set(CMAKE_C_FLAGS_RELEASE "-O3 ")
 endif()

+if(MSVC)
+  # Prevent linking to vcruntime140.dll which would interfere with libsndfile
+  set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} /MTd")
+  set(CMAKE_C_FLAGS_MINSIZEREL "${CMAKE_C_FLAGS_MINSIZEREL} /MT")
+  set(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} /MT")
+  set(CMAKE_C_FLAGS_RELWITHDEBINFO "${CMAKE_C_FLAGS_RELWITHDEBINFO} /MT")
+  if(CMAKE_BUILD_TYPE STREQUAL "")
+    # default build is a debug build
+    set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /MTd")
+  endif()
+endif()
+
 # Project definitions
 set(APIVERSION "6.0")



And while it doesn't show in CMakeCache.txt, this does seem to update
the flags within the VS solution with /MT and /MTd.  However, the
compiled .exe and .dlls still show a link to vcruntime140.dll.


Anyone else have ideas?

steven

I've made the change but I was running into problems with building locally. It should be as simple as removing the libsndfile download URL and adding libsndfile to the VCPKG install command. Give it a try and see how it goes.  I'll try and submit what I have later.

A note on the vcruntime, we don't compile it statically currently. Same for the VCPKG depdendencies. They don't link with the CRT statically either. It is possible to do so. In fact, it might solve the problem with copying the libraries for packaging. Maybe it's worth trying.

Stephen

---

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Steven Yi <stevenyi@GMAIL.COM>
Sent: 23 August 2017 17:00

To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: Re: [Csnd-dev] libsndfile and MSVC build

 

I guess if the root of this problem with the fairlight.csd example is indeed the differerent C runtimes, and if using the vcpkg version of libsndfile gets us on the same dll and solves the problem, then that'd be the way to go.  (Assuming we also package the vcruntimex.dll with the release.)   

BTW: Did you try any changes to use the libsndfile from vcpkg already?  I'm trying it out locally now. 

On Tue, Aug 22, 2017 at 4:53 PM, Stephen Kyne <stevek@outlook.ie> wrote:

Hey Steven,

With the VCPKG version of libsndfile, it will download the source and build locally so it will build with the same CRT version as being built with Csound. Which will most likely be the 2017 version. From what you described, the two were using different versions of the runtime.

https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL.2C_MSVCP.2A.DLL_and_CRTDLL.DLL 

That link mentions that msvcrt.dll is the old version but newer versions use vcruntimeX.dll. 140 is 2015, 150 is 2017 afaik.

So the end user only needs the 2017 runtime distributable then and everything should work fine I guess!

Stephen

---

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Steven Yi <stevenyi@GMAIL.COM>
Sent: 22 August 2017 21:28
To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: Re: [Csnd-dev] libsndfile and MSVC build

 

Hi Stephen,

I don't know much about differences between vcruntime140.dll and msvcrt.dll, but it seems if we can get away without using vcruntime140.dll altogether, that'd be better for covering more Windows installations, no?  (Or, I'm misunderstanding something altogether about these two libs...)

steven

On Sat, Aug 19, 2017 at 7:44 AM, Stephen Kyne <stevek@outlook.ie> wrote:

Hi Steven,

I just saw that libsndfile is actually in vcpkg. So we could just build it from source this way and probably get around this issue. I'll make the change and see how it goes.

Thanks,

Stephen

---

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Steven Yi <stevenyi@GMAIL.COM>
Sent: 18 August 2017 19:44
To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: [Csnd-dev] libsndfile and MSVC build

 

Hi All,

I've been tracing through the file issue I reported regarding the
fairlight.csd example.  I was stepping through code with Visual
Studio's debugger as well as with XCode's. The variables and code
paths were matching until getting to envvar.c:1098. After this, p->sf
was NULL in VS but it was populated with values on XCode.  In looking
around, I found this comment on libsndfile's site
(http://www.mega-nerd.com/libsndfile/api.html#open_fd):

The libsndfile API - Mega Nerd www.mega-nerd.com Libsndfile is a library designed to allow the reading and writing of many different sampled sound file formats (such as MS Windows WAV and the Apple/SGI AIFF format ...

File Descriptor Open

      SNDFILE*  sf_open_fd (int fd, int mode, SF_INFO *sfinfo, int close_desc) ;

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.

Using dependency walker, I saw that libsndfile linked to msvcrt.dll,
but csound was linking to vcruntime140.dll.

Now, I'm not sure this is it, but seems like a good lead.  I've tried
adding the use of /MTd and /MT when compiling:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 050307cd7..dbe88c565 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -20,6 +20,18 @@ set(CMAKE_CXX_FLAGS_RELEASE "-O3 ")
 set(CMAKE_C_FLAGS_RELEASE "-O3 ")
 endif()

+if(MSVC)
+  # Prevent linking to vcruntime140.dll which would interfere with libsndfile
+  set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} /MTd")
+  set(CMAKE_C_FLAGS_MINSIZEREL "${CMAKE_C_FLAGS_MINSIZEREL} /MT")
+  set(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} /MT")
+  set(CMAKE_C_FLAGS_RELWITHDEBINFO "${CMAKE_C_FLAGS_RELWITHDEBINFO} /MT")
+  if(CMAKE_BUILD_TYPE STREQUAL "")
+    # default build is a debug build
+    set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /MTd")
+  endif()
+endif()
+
 # Project definitions
 set(APIVERSION "6.0")



And while it doesn't show in CMakeCache.txt, this does seem to update
the flags within the VS solution with /MT and /MTd.  However, the
compiled .exe and .dlls still show a link to vcruntime140.dll.


Anyone else have ideas?

steven

Hmm that’s strange. It shouldn’t mix Release and Debug like that. Having looked at your diff, it seems you didn’t delete the binary download version of libsndfile. You’ll have to remove that or else it will probably find that extracted version and use it.

 

The VCPKG version won’t mix Debug/Release, it will always align them correctly based on the current build configuration.

 

Stephen

 

From: Steven Yi
Sent: Wednesday 23 August 2017 21:51
To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: Re: [Csnd-dev] libsndfile and MSVC build

 

I did a build using the git diff pasted below. What ended up happening was that libsndfile-1.dll was built linked to vcruntime140d.dll and ucrbased.dll, but libcsound.dll is linked to vcruntime140.dll.  Upon running the test csd, I get an exception with the stack trace coming from ucrtbased.dll, called from libsndfile. It all seems a bit of a mess and I'm not sure what to do next. 

 

 

$ git diff

diff --git a/msvc/downloadDependencies.ps1 b/msvc/downloadDependencies.ps1

index 0df05a052..228661da8 100644

--- a/msvc/downloadDependencies.ps1

+++ b/msvc/downloadDependencies.ps1

@@ -96,7 +96,7 @@ New-Item -type file $vcpkgDir\downloads\AlwaysAllowDownloads -errorAction Silent

 echo "Downloading VC packages..."

 # Target can be arm-uwp, x64-uwp, x64-windows-static, x64-windows, x86-uwp, x86-windows-static, x86-windows

 $targetTriplet = "x64-windows"

-vcpkg --triplet $targetTriplet install eigen3 fltk libflac libogg libvorbis zlib

+vcpkg --triplet $targetTriplet install eigen3 fltk libflac libogg libvorbis zlib libsndfile

 $vcpkgTiming = (Get-Date).TimeOfDay

 

 # Comment for testing to avoid extracting if already done so

@@ -108,8 +108,7 @@ mkdir staging -ErrorAction SilentlyContinue

 echo "Downloading and installing non-VCPKG packages..."

 

 # List of URIs to download and install

-$uriList="http://www.mega-nerd.com/libsndfile/files/libsndfile-1.0.28-w64.zip",

-"https://downloads.sourceforge.net/project/winflexbison/win_flex_bison-latest.zip",

+$uriList="https://downloads.sourceforge.net/project/winflexbison/win_flex_bison-latest.zip",

 "http://www.steinberg.net/sdk_downloads/asiosdk2.3.zip",

 "https://downloads.sourceforge.net/project/swig/swigwin/swigwin-3.0.12/swigwin-3.0.12.zip",

 #"http://www.steinberg.net/sdk_downloads/vstsdk367_03_03_2017_build_352.zip",

@@ -122,8 +121,7 @@ $uriList="http://www.mega-nerd.com/libsndfile/files/libsndfile-1.0.28-w64.zip",

 "https://github.com/thestk/stk/archive/master.zip"

 

 # Appends this folder location to the 'deps' uri

-$destList="",

-"win_flex_bison",

+$destList="win_flex_bison",

 "",

 "",

 "fluidsynthdeps",

@@ -297,7 +295,7 @@ if (Test-Path "CsoundQt")

 }

 else

 {

-    git clone "https://github.com/CsoundQt/CsoundQt.git"

+    git clone --depth=1 "https://github.com/CsoundQt/CsoundQt.git"

     cd CsoundQt

 }

 git checkout tags/0.9.5-beta

 

 

On Wed, Aug 23, 2017 at 4:08 PM, Stephen Kyne <stevek@outlook.ie> wrote:

I've made the change but I was running into problems with building locally. It should be as simple as removing the libsndfile download URL and adding libsndfile to the VCPKG install command. Give it a try and see how it goes.  I'll try and submit what I have later.

 

A note on the vcruntime, we don't compile it statically currently. Same for the VCPKG depdendencies. They don't link with the CRT statically either. It is possible to do so. In fact, it might solve the problem with copying the libraries for packaging. Maybe it's worth trying.

 

Stephen

 

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Steven Yi <stevenyi@GMAIL.COM>
Sent: 23 August 2017 17:00

To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: Re: [Csnd-dev] libsndfile and MSVC build

 

I guess if the root of this problem with the fairlight.csd example is indeed the differerent C runtimes, and if using the vcpkg version of libsndfile gets us on the same dll and solves the problem, then that'd be the way to go.  (Assuming we also package the vcruntimex.dll with the release.)   

 

BTW: Did you try any changes to use the libsndfile from vcpkg already?  I'm trying it out locally now. 

 

 

 

On Tue, Aug 22, 2017 at 4:53 PM, Stephen Kyne <stevek@outlook.ie> wrote:

Hey Steven,

 

With the VCPKG version of libsndfile, it will download the source and build locally so it will build with the same CRT version as being built with Csound. Which will most likely be the 2017 version. From what you described, the two were using different versions of the runtime.

https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL.2C_MSVCP.2A.DLL_and_CRTDLL.DLL 

That link mentions that msvcrt.dll is the old version but newer versions use vcruntimeX.dll. 140 is 2015, 150 is 2017 afaik.

 

So the end user only needs the 2017 runtime distributable then and everything should work fine I guess!

 

Stephen

 

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Steven Yi <stevenyi@GMAIL.COM>
Sent: 22 August 2017 21:28
To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: Re: [Csnd-dev] libsndfile and MSVC build

 

Hi Stephen,

 

I don't know much about differences between vcruntime140.dll and msvcrt.dll, but it seems if we can get away without using vcruntime140.dll altogether, that'd be better for covering more Windows installations, no?  (Or, I'm misunderstanding something altogether about these two libs...)

 

steven

 

 

 

On Sat, Aug 19, 2017 at 7:44 AM, Stephen Kyne <stevek@outlook.ie> wrote:

Hi Steven,

 

I just saw that libsndfile is actually in vcpkg. So we could just build it from source this way and probably get around this issue. I'll make the change and see how it goes.

 

Thanks,

Stephen

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Steven Yi <stevenyi@GMAIL.COM>
Sent: 18 August 2017 19:44
To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: [Csnd-dev] libsndfile and MSVC build

 

Hi All,

I've been tracing through the file issue I reported regarding the
fairlight.csd example.  I was stepping through code with Visual
Studio's debugger as well as with XCode's. The variables and code
paths were matching until getting to envvar.c:1098. After this, p->sf
was NULL in VS but it was populated with values on XCode.  In looking
around, I found this comment on libsndfile's site
(http://www.mega-nerd.com/libsndfile/api.html#open_fd):

The libsndfile API - Mega Nerd www.mega-nerd.com Libsndfile is a library designed to allow the reading and writing of many different sampled sound file formats (such as MS Windows WAV and the Apple/SGI AIFF format ...

File Descriptor Open

      SNDFILE*  sf_open_fd (int fd, int mode, SF_INFO *sfinfo, int close_desc) ;

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.

Using dependency walker, I saw that libsndfile linked to msvcrt.dll,
but csound was linking to vcruntime140.dll.

Now, I'm not sure this is it, but seems like a good lead.  I've tried
adding the use of /MTd and /MT when compiling:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 050307cd7..dbe88c565 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -20,6 +20,18 @@ set(CMAKE_CXX_FLAGS_RELEASE "-O3 ")
 set(CMAKE_C_FLAGS_RELEASE "-O3 ")
 endif()

+if(MSVC)
+  # Prevent linking to vcruntime140.dll which would interfere with libsndfile
+  set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} /MTd")
+  set(CMAKE_C_FLAGS_MINSIZEREL "${CMAKE_C_FLAGS_MINSIZEREL} /MT")
+  set(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} /MT")
+  set(CMAKE_C_FLAGS_RELWITHDEBINFO "${CMAKE_C_FLAGS_RELWITHDEBINFO} /MT")
+  if(CMAKE_BUILD_TYPE STREQUAL "")
+    # default build is a debug build
+    set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /MTd")
+  endif()
+endif()
+
 # Project definitions
 set(APIVERSION "6.0")



And while it doesn't show in CMakeCache.txt, this does seem to update
the flags within the VS solution with /MT and /MTd.  However, the
compiled .exe and .dlls still show a link to vcruntime140.dll.


Anyone else have ideas?

steven

 

 

 

 

Oh sorry, didn’t scroll down enough...

 

I didn’t think that build type really mattered. Whatever is selected in VS should supersede the CMake configuration I think.

 

Where are you seeing the libsndfile.dll actually after the build? There is a problem where the binaries are not copied to the output dir if the project is a DLL (as opposed to an executable).

 

I’m pretty sure, because we saw issues with Python, that the debug version will copy the debug VCPKG binaries and vice versa.

 

Stephen

 

From: Steven Yi
Sent: Wednesday 23 August 2017 22:05

To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: Re: [Csnd-dev] libsndfile and MSVC build

 

As far as I understand, this part of the diff:

 

 # List of URIs to download and install

-$uriList="http://www.mega-nerd.com/libsndfile/files/libsndfile-1.0.28-w64.zip",

-"https://downloads.sourceforge.net/project/winflexbison/win_flex_bison-latest.zip",

+$uriList="https://downloads.sourceforge.net/project/winflexbison/win_flex_bison-latest.zip",

 "http://www.steinberg.net/sdk_downloads/asiosdk2.3.zip",

 

took out the binary download of libsndfile, so I don't think that is it.  

 

It's odd as I'm building Debug within VS itself, but release is the build type used when generating the project.  Not sure if that's the cause of things?

 

On Wed, Aug 23, 2017 at 4:54 PM, Stephen Kyne <stevek@outlook.ie> wrote:

Hmm that’s strange. It shouldn’t mix Release and Debug like that. Having looked at your diff, it seems you didn’t delete the binary download version of libsndfile. You’ll have to remove that or else it will probably find that extracted version and use it.

 

The VCPKG version won’t mix Debug/Release, it will always align them correctly based on the current build configuration.

 

Stephen

 

From: Steven Yi
Sent: Wednesday 23 August 2017 21:51
To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: Re: [Csnd-dev] libsndfile and MSVC build

 

I did a build using the git diff pasted below. What ended up happening was that libsndfile-1.dll was built linked to vcruntime140d.dll and ucrbased.dll, but libcsound.dll is linked to vcruntime140.dll.  Upon running the test csd, I get an exception with the stack trace coming from ucrtbased.dll, called from libsndfile. It all seems a bit of a mess and I'm not sure what to do next. 

 

 

$ git diff

diff --git a/msvc/downloadDependencies.ps1 b/msvc/downloadDependencies.ps1

index 0df05a052..228661da8 100644

--- a/msvc/downloadDependencies.ps1

+++ b/msvc/downloadDependencies.ps1

@@ -96,7 +96,7 @@ New-Item -type file $vcpkgDir\downloads\AlwaysAllowDownloads -errorAction Silent

 echo "Downloading VC packages..."

 # Target can be arm-uwp, x64-uwp, x64-windows-static, x64-windows, x86-uwp, x86-windows-static, x86-windows

 $targetTriplet = "x64-windows"

-vcpkg --triplet $targetTriplet install eigen3 fltk libflac libogg libvorbis zlib

+vcpkg --triplet $targetTriplet install eigen3 fltk libflac libogg libvorbis zlib libsndfile

 $vcpkgTiming = (Get-Date).TimeOfDay

 

 # Comment for testing to avoid extracting if already done so

@@ -108,8 +108,7 @@ mkdir staging -ErrorAction SilentlyContinue

 echo "Downloading and installing non-VCPKG packages..."

 

 # List of URIs to download and install

-$uriList="http://www.mega-nerd.com/libsndfile/files/libsndfile-1.0.28-w64.zip",

-"https://downloads.sourceforge.net/project/winflexbison/win_flex_bison-latest.zip",

+$uriList="https://downloads.sourceforge.net/project/winflexbison/win_flex_bison-latest.zip",

 "http://www.steinberg.net/sdk_downloads/asiosdk2.3.zip",

 "https://downloads.sourceforge.net/project/swig/swigwin/swigwin-3.0.12/swigwin-3.0.12.zip",

 #"http://www.steinberg.net/sdk_downloads/vstsdk367_03_03_2017_build_352.zip",

@@ -122,8 +121,7 @@ $uriList="http://www.mega-nerd.com/libsndfile/files/libsndfile-1.0.28-w64.zip",

 "https://github.com/thestk/stk/archive/master.zip"

 

 # Appends this folder location to the 'deps' uri

-$destList="",

-"win_flex_bison",

+$destList="win_flex_bison",

 "",

 "",

 "fluidsynthdeps",

@@ -297,7 +295,7 @@ if (Test-Path "CsoundQt")

 }

 else

 {

-    git clone "https://github.com/CsoundQt/CsoundQt.git"

+    git clone --depth=1 "https://github.com/CsoundQt/CsoundQt.git"

     cd CsoundQt

 }

 git checkout tags/0.9.5-beta

 

 

On Wed, Aug 23, 2017 at 4:08 PM, Stephen Kyne <stevek@outlook.ie> wrote:

I've made the change but I was running into problems with building locally. It should be as simple as removing the libsndfile download URL and adding libsndfile to the VCPKG install command. Give it a try and see how it goes.  I'll try and submit what I have later.

 

A note on the vcruntime, we don't compile it statically currently. Same for the VCPKG depdendencies. They don't link with the CRT statically either. It is possible to do so. In fact, it might solve the problem with copying the libraries for packaging. Maybe it's worth trying.

 

Stephen

 

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Steven Yi <stevenyi@GMAIL.COM>
Sent: 23 August 2017 17:00

To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: Re: [Csnd-dev] libsndfile and MSVC build

 

I guess if the root of this problem with the fairlight.csd example is indeed the differerent C runtimes, and if using the vcpkg version of libsndfile gets us on the same dll and solves the problem, then that'd be the way to go.  (Assuming we also package the vcruntimex.dll with the release.)   

 

BTW: Did you try any changes to use the libsndfile from vcpkg already?  I'm trying it out locally now. 

 

 

 

On Tue, Aug 22, 2017 at 4:53 PM, Stephen Kyne <stevek@outlook.ie> wrote:

Hey Steven,

 

With the VCPKG version of libsndfile, it will download the source and build locally so it will build with the same CRT version as being built with Csound. Which will most likely be the 2017 version. From what you described, the two were using different versions of the runtime.

https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL.2C_MSVCP.2A.DLL_and_CRTDLL.DLL 

That link mentions that msvcrt.dll is the old version but newer versions use vcruntimeX.dll. 140 is 2015, 150 is 2017 afaik.

 

So the end user only needs the 2017 runtime distributable then and everything should work fine I guess!

 

Stephen

 

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Steven Yi <stevenyi@GMAIL.COM>
Sent: 22 August 2017 21:28
To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: Re: [Csnd-dev] libsndfile and MSVC build

 

Hi Stephen,

 

I don't know much about differences between vcruntime140.dll and msvcrt.dll, but it seems if we can get away without using vcruntime140.dll altogether, that'd be better for covering more Windows installations, no?  (Or, I'm misunderstanding something altogether about these two libs...)

 

steven

 

 

 

On Sat, Aug 19, 2017 at 7:44 AM, Stephen Kyne <stevek@outlook.ie> wrote:

Hi Steven,

 

I just saw that libsndfile is actually in vcpkg. So we could just build it from source this way and probably get around this issue. I'll make the change and see how it goes.

 

Thanks,

Stephen

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Steven Yi <stevenyi@GMAIL.COM>
Sent: 18 August 2017 19:44
To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: [Csnd-dev] libsndfile and MSVC build

 

Hi All,

I've been tracing through the file issue I reported regarding the
fairlight.csd example.  I was stepping through code with Visual
Studio's debugger as well as with XCode's. The variables and code
paths were matching until getting to envvar.c:1098. After this, p->sf
was NULL in VS but it was populated with values on XCode.  In looking
around, I found this comment on libsndfile's site
(http://www.mega-nerd.com/libsndfile/api.html#open_fd):

The libsndfile API - Mega Nerd www.mega-nerd.com Libsndfile is a library designed to allow the reading and writing of many different sampled sound file formats (such as MS Windows WAV and the Apple/SGI AIFF format ...

File Descriptor Open

      SNDFILE*  sf_open_fd (int fd, int mode, SF_INFO *sfinfo, int close_desc) ;

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.

Using dependency walker, I saw that libsndfile linked to msvcrt.dll,
but csound was linking to vcruntime140.dll.

Now, I'm not sure this is it, but seems like a good lead.  I've tried
adding the use of /MTd and /MT when compiling:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 050307cd7..dbe88c565 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -20,6 +20,18 @@ set(CMAKE_CXX_FLAGS_RELEASE "-O3 ")
 set(CMAKE_C_FLAGS_RELEASE "-O3 ")
 endif()

+if(MSVC)
+  # Prevent linking to vcruntime140.dll which would interfere with libsndfile
+  set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} /MTd")
+  set(CMAKE_C_FLAGS_MINSIZEREL "${CMAKE_C_FLAGS_MINSIZEREL} /MT")
+  set(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} /MT")
+  set(CMAKE_C_FLAGS_RELWITHDEBINFO "${CMAKE_C_FLAGS_RELWITHDEBINFO} /MT")
+  if(CMAKE_BUILD_TYPE STREQUAL "")
+    # default build is a debug build
+    set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /MTd")
+  endif()
+endif()
+
 # Project definitions
 set(APIVERSION "6.0")



And while it doesn't show in CMakeCache.txt, this does seem to update
the flags within the VS solution with /MT and /MTd.  However, the
compiled .exe and .dlls still show a link to vcruntime140.dll.


Anyone else have ideas?

steven

 

 

 

 

 

 

libsndfile-1.dll shows up in the csound-vs/Debug folder where the csound.exe gets built.  So building that target is pulling in the vcpkg version of the libsndfile dll. 

OH... success! Okay, sort of. If I compile using RelWithDebInfo build type in VS, it now correctly runs my fairlight.csd with VS-compiled csound.  At this point, I think there's two things to note:

1. Linking with multiple C runtimes was indeed the problem in running the example CSD.

2. Compiling csound64.dll seems to always link with release vcruntime140.dll, when it should probably link with vcruntime140d.dll when Debug build is used.  

I suppose I'll just use RelWithDebInfo for now, but it would be very nice to figure out what's going on with the Debug build and linking as it'd make development a bit easier (for me at least!). 

On Wed, Aug 23, 2017 at 5:10 PM, Stephen Kyne <stevek@outlook.ie> wrote:

Oh sorry, didn’t scroll down enough...

 

I didn’t think that build type really mattered. Whatever is selected in VS should supersede the CMake configuration I think.

 

Where are you seeing the libsndfile.dll actually after the build? There is a problem where the binaries are not copied to the output dir if the project is a DLL (as opposed to an executable).

 

I’m pretty sure, because we saw issues with Python, that the debug version will copy the debug VCPKG binaries and vice versa.

 

Stephen

 

From: Steven Yi
Sent: Wednesday 23 August 2017 22:05

To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: Re: [Csnd-dev] libsndfile and MSVC build

 

As far as I understand, this part of the diff:

 

 # List of URIs to download and install

-$uriList="http://www.mega-nerd.com/libsndfile/files/libsndfile-1.0.28-w64.zip",

-"https://downloads.sourceforge.net/project/winflexbison/win_flex_bison-latest.zip",

+$uriList="https://downloads.sourceforge.net/project/winflexbison/win_flex_bison-latest.zip",

 "http://www.steinberg.net/sdk_downloads/asiosdk2.3.zip",

 

took out the binary download of libsndfile, so I don't think that is it.  

 

It's odd as I'm building Debug within VS itself, but release is the build type used when generating the project.  Not sure if that's the cause of things?

 

On Wed, Aug 23, 2017 at 4:54 PM, Stephen Kyne <stevek@outlook.ie> wrote:

Hmm that’s strange. It shouldn’t mix Release and Debug like that. Having looked at your diff, it seems you didn’t delete the binary download version of libsndfile. You’ll have to remove that or else it will probably find that extracted version and use it.

 

The VCPKG version won’t mix Debug/Release, it will always align them correctly based on the current build configuration.

 

Stephen

 

From: Steven Yi
Sent: Wednesday 23 August 2017 21:51
To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: Re: [Csnd-dev] libsndfile and MSVC build

 

I did a build using the git diff pasted below. What ended up happening was that libsndfile-1.dll was built linked to vcruntime140d.dll and ucrbased.dll, but libcsound.dll is linked to vcruntime140.dll.  Upon running the test csd, I get an exception with the stack trace coming from ucrtbased.dll, called from libsndfile. It all seems a bit of a mess and I'm not sure what to do next. 

 

 

$ git diff

diff --git a/msvc/downloadDependencies.ps1 b/msvc/downloadDependencies.ps1

index 0df05a052..228661da8 100644

--- a/msvc/downloadDependencies.ps1

+++ b/msvc/downloadDependencies.ps1

@@ -96,7 +96,7 @@ New-Item -type file $vcpkgDir\downloads\AlwaysAllowDownloads -errorAction Silent

 echo "Downloading VC packages..."

 # Target can be arm-uwp, x64-uwp, x64-windows-static, x64-windows, x86-uwp, x86-windows-static, x86-windows

 $targetTriplet = "x64-windows"

-vcpkg --triplet $targetTriplet install eigen3 fltk libflac libogg libvorbis zlib

+vcpkg --triplet $targetTriplet install eigen3 fltk libflac libogg libvorbis zlib libsndfile

 $vcpkgTiming = (Get-Date).TimeOfDay

 

 # Comment for testing to avoid extracting if already done so

@@ -108,8 +108,7 @@ mkdir staging -ErrorAction SilentlyContinue

 echo "Downloading and installing non-VCPKG packages..."

 

 # List of URIs to download and install

-$uriList="http://www.mega-nerd.com/libsndfile/files/libsndfile-1.0.28-w64.zip",

-"https://downloads.sourceforge.net/project/winflexbison/win_flex_bison-latest.zip",

+$uriList="https://downloads.sourceforge.net/project/winflexbison/win_flex_bison-latest.zip",

 "http://www.steinberg.net/sdk_downloads/asiosdk2.3.zip",

 "https://downloads.sourceforge.net/project/swig/swigwin/swigwin-3.0.12/swigwin-3.0.12.zip",

 #"http://www.steinberg.net/sdk_downloads/vstsdk367_03_03_2017_build_352.zip",

@@ -122,8 +121,7 @@ $uriList="http://www.mega-nerd.com/libsndfile/files/libsndfile-1.0.28-w64.zip",

 "https://github.com/thestk/stk/archive/master.zip"

 

 # Appends this folder location to the 'deps' uri

-$destList="",

-"win_flex_bison",

+$destList="win_flex_bison",

 "",

 "",

 "fluidsynthdeps",

@@ -297,7 +295,7 @@ if (Test-Path "CsoundQt")

 }

 else

 {

-    git clone "https://github.com/CsoundQt/CsoundQt.git"

+    git clone --depth=1 "https://github.com/CsoundQt/CsoundQt.git"

     cd CsoundQt

 }

 git checkout tags/0.9.5-beta

 

 

On Wed, Aug 23, 2017 at 4:08 PM, Stephen Kyne <stevek@outlook.ie> wrote:

I've made the change but I was running into problems with building locally. It should be as simple as removing the libsndfile download URL and adding libsndfile to the VCPKG install command. Give it a try and see how it goes.  I'll try and submit what I have later.

 

A note on the vcruntime, we don't compile it statically currently. Same for the VCPKG depdendencies. They don't link with the CRT statically either. It is possible to do so. In fact, it might solve the problem with copying the libraries for packaging. Maybe it's worth trying.

 

Stephen

 

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Steven Yi <stevenyi@GMAIL.COM>
Sent: 23 August 2017 17:00

To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: Re: [Csnd-dev] libsndfile and MSVC build

 

I guess if the root of this problem with the fairlight.csd example is indeed the differerent C runtimes, and if using the vcpkg version of libsndfile gets us on the same dll and solves the problem, then that'd be the way to go.  (Assuming we also package the vcruntimex.dll with the release.)   

 

BTW: Did you try any changes to use the libsndfile from vcpkg already?  I'm trying it out locally now. 

 

 

 

On Tue, Aug 22, 2017 at 4:53 PM, Stephen Kyne <stevek@outlook.ie> wrote:

Hey Steven,

 

With the VCPKG version of libsndfile, it will download the source and build locally so it will build with the same CRT version as being built with Csound. Which will most likely be the 2017 version. From what you described, the two were using different versions of the runtime.

https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL.2C_MSVCP.2A.DLL_and_CRTDLL.DLL 

That link mentions that msvcrt.dll is the old version but newer versions use vcruntimeX.dll. 140 is 2015, 150 is 2017 afaik.

 

So the end user only needs the 2017 runtime distributable then and everything should work fine I guess!

 

Stephen

 

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Steven Yi <stevenyi@GMAIL.COM>
Sent: 22 August 2017 21:28
To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: Re: [Csnd-dev] libsndfile and MSVC build

 

Hi Stephen,

 

I don't know much about differences between vcruntime140.dll and msvcrt.dll, but it seems if we can get away without using vcruntime140.dll altogether, that'd be better for covering more Windows installations, no?  (Or, I'm misunderstanding something altogether about these two libs...)

 

steven

 

 

 

On Sat, Aug 19, 2017 at 7:44 AM, Stephen Kyne <stevek@outlook.ie> wrote:

Hi Steven,

 

I just saw that libsndfile is actually in vcpkg. So we could just build it from source this way and probably get around this issue. I'll make the change and see how it goes.

 

Thanks,

Stephen

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Steven Yi <stevenyi@GMAIL.COM>
Sent: 18 August 2017 19:44
To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: [Csnd-dev] libsndfile and MSVC build

 

Hi All,

I've been tracing through the file issue I reported regarding the
fairlight.csd example.  I was stepping through code with Visual
Studio's debugger as well as with XCode's. The variables and code
paths were matching until getting to envvar.c:1098. After this, p->sf
was NULL in VS but it was populated with values on XCode.  In looking
around, I found this comment on libsndfile's site
(http://www.mega-nerd.com/libsndfile/api.html#open_fd):

The libsndfile API - Mega Nerd www.mega-nerd.com Libsndfile is a library designed to allow the reading and writing of many different sampled sound file formats (such as MS Windows WAV and the Apple/SGI AIFF format ...

File Descriptor Open

      SNDFILE*  sf_open_fd (int fd, int mode, SF_INFO *sfinfo, int close_desc) ;

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.

Using dependency walker, I saw that libsndfile linked to msvcrt.dll,
but csound was linking to vcruntime140.dll.

Now, I'm not sure this is it, but seems like a good lead.  I've tried
adding the use of /MTd and /MT when compiling:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 050307cd7..dbe88c565 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -20,6 +20,18 @@ set(CMAKE_CXX_FLAGS_RELEASE "-O3 ")
 set(CMAKE_C_FLAGS_RELEASE "-O3 ")
 endif()

+if(MSVC)
+  # Prevent linking to vcruntime140.dll which would interfere with libsndfile
+  set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} /MTd")
+  set(CMAKE_C_FLAGS_MINSIZEREL "${CMAKE_C_FLAGS_MINSIZEREL} /MT")
+  set(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} /MT")
+  set(CMAKE_C_FLAGS_RELWITHDEBINFO "${CMAKE_C_FLAGS_RELWITHDEBINFO} /MT")
+  if(CMAKE_BUILD_TYPE STREQUAL "")
+    # default build is a debug build
+    set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /MTd")
+  endif()
+endif()
+
 # Project definitions
 set(APIVERSION "6.0")



And while it doesn't show in CMakeCache.txt, this does seem to update
the flags within the VS solution with /MT and /MTd.  However, the
compiled .exe and .dlls still show a link to vcruntime140.dll.


Anyone else have ideas?

steven