Skip to content

Building in Windows with VS2015, how to make static build? #199

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
altbdoor opened this issue Nov 26, 2016 · 5 comments
Closed

Building in Windows with VS2015, how to make static build? #199

altbdoor opened this issue Nov 26, 2016 · 5 comments

Comments

@altbdoor
Copy link

In reference to the docs on building on Windows, I have successfully built a sassc.exe by following the steps with VS2015. But when I copy the built sassc.exe to another computer, it complains that sassc was unable to find a shared folder.

sassc.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory

I would assume that the library in question here is libsass.dll. I noticed that the .travis.yml settings have a setting for BUILD, where it can be static or shared. But guides on building sassc (in both Unix and Windows) did not mention anything about this.

So question is, is it possible to make a sassc static build? If yes, how do I proceed with VS2015?

@am11
Copy link
Contributor

am11 commented Dec 10, 2016

@altbdoor, I am unable to reproduce this error as we are already compiling libsass statically in VCR builds. On the contrary, I wanted to add the dll shared lib / DLL configuration in addition to static one that we already have. :)

I have verified with the following steps using command line:

:: on my system running Windows 10 x86 Enterprise, changed directory to c:\temp
cd \temp

:: cloned LibSass
git clone https://github.com/sass/libsass
cd libsass

:: cloned SassC inside LibSass dir
git clone https://github.com/sass/sassc

:: compiled using MSBuild 14.0 (that ships with VS 2015):
"%ProgramFiles(x86)%\MSBuild\14.0\Bin\MSBuild" sassc\win\sassc.sln /p:Configuration=Release

:: created a test Sass file, test.scss
echo a{b:c} > test.scss

:: compiled with SassC
sassc\bin\sassc test.scss

:: resulted in:
a {
  b: c; }

Opened RDC and logged into a Azure VM running Windows Server 2012 R2 x64 Datacenter edition and copied sassc.exe and test.scss in a directory and ran sassc test.scss and got the same results.

Is your source and target OSes have same bitness (x86_64 or x86_32)?

@am11
Copy link
Contributor

am11 commented Dec 10, 2016

If the bitness is same, then I think you might need to have at least VS2015 Redistributable package installed on your target machine (as we have full blown VS2015 installed on our VM).

@am11
Copy link
Contributor

am11 commented Dec 10, 2016

@mgreter, @xzyfer, assuming bitness of target and source were same in the copy/pasta 🍝 of binaries scenario that @altbdoor has specified (which I am inkling on), is it OK to declare in readme that the redistributed runtime package is a prerequisite of sassc for Windows?

Alternatively, we can inline or static compile the required pieces of runtime using /MT for Release and /MTd for Debug flags (as opposed to /MD for Release or /MDd for Debug what we have now and what requires the redistributable package to be required on target OS).

The redistributable package is ~13 MBs.
However, the ramification of static compiling the runtime in terms of our binary size is:

Before: 920 KB
After: 1,307 KB

in Release configuration.

Here is the diff that we would need to apply in win/sassc.vcxproj file:

diff --git a/win/sassc.vcxproj b/win/sassc.vcxproj
index ea3032e..7cead31 100644
--- a/win/sassc.vcxproj
+++ b/win/sassc.vcxproj
@@ -113,6 +113,7 @@
       <WarningLevel>Level3</WarningLevel>
       <Optimization>Disabled</Optimization>
       <PreprocessorDefinitions>WIN32;_DEBUG;_CONSOLE;_LIB;%(PreprocessorDefinitions)</PreprocessorDefinitions>
+      <RuntimeLibrary>MultiThreadedDebug</RuntimeLibrary>
     </ClCompile>
     <Link>
       <SubSystem>Console</SubSystem>
@@ -141,6 +142,7 @@
       <FunctionLevelLinking>true</FunctionLevelLinking>
       <IntrinsicFunctions>true</IntrinsicFunctions>
       <PreprocessorDefinitions>WIN32;NDEBUG;_CONSOLE;_LIB;%(PreprocessorDefinitions)</PreprocessorDefinitions>
+      <RuntimeLibrary>MultiThreaded</RuntimeLibrary>
     </ClCompile>
     <Link>
       <SubSystem>Console</SubSystem>

@altbdoor
Copy link
Author

Odd, I myself was not able to reproduce the error. I think I might have messed up in between all the binaries I made, apologies for the trouble.

If the bitness is same, then I think you might need to have at least VS2015 Redistributable package installed on your target machine (as we have full blown VS2015 installed on our VM).

This bit did help. After recompiling sassc, it did complain that MSVCP140.dll is missing, and installing the Redistributable package solved it.

But as recommended by @am11, it would be nice to inline or static compile the dependencies into a single executable.

@am11
Copy link
Contributor

am11 commented Dec 11, 2016

Thanks for the confirmation @altbdoor!

it would be nice to inline or static compile the dependencies into a single executable.

I have opened a PR #201 and changed Release and Debug configurations to inline the runtime. Also added Release without static runtime and Debug without static runtime configurations, which are the recommended configurations as I have described in the docs: https://github.com/sass/sassc/blob/build/win/gh-199/docs/building/windows-instructions.md. Now we have both options.

The recommendation from vendor in their redistribution docs is to not static compile the binaries or distilling them against specific runtime as the next patch update of redistributable package may fix some potential bug. Also folks in some Stack Overflow answers have also recommended the same. But we are issuing the warning "the recommended config is shared, use static at your own risk"! :)

mgreter added a commit that referenced this issue Dec 15, 2016
Ability to static compile VCR libs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants