Problems getting libsass to compile on windows

[schneems]

I'm the open source maintainer of Sprockets. I'm trying to get sassc (libsass) supported natively, here's the PR: rails/sprockets#349. Turns out that sassc-ruby doesn't work on windows. I'm trying to fix that but before I can, i'm not able to get it to compile on appveyor (PR for testing on my fork schneems/sassc-ruby#1). Here's the related windows discussion: sass/sassc-ruby#18 (comment).

That's the background.

I'm here to ask for help in getting libsass compiling on appveyor for the sassc-ruby gem. This isn't an "issue" per-say but rather a request. I can't offer much in return other than to support libsass for sprockets users, I can also buy you a delivery pizza (totally serious, i've done this before). I need help getting sassc-ruby to a place where it can compile libsass on appveyor.

I've attempted a few things on that issue, but i'm mostly shooting in the dark. The current makefile won't install with nmake due to it complaining about syntax. I looked at the appveyor.yml of this project but it looks sufficiently complicated, i don't totally know what's going on. I tried getting a VM of windows installed locally but ran into a problem when it doesn't have mingw32-make and the msbuild command is fails.

> msbuild win/libsass.sln

Gives me:

Any ideas on the best way to move forwards getting libsass to compile for testing sassc-ruby on windows? Any help is greatly appreciated.

p.s. Serious about the 🍕

[xzyfer]

You had me at pizza. But seriously I'm excited to see this happening in sprockets. @am11 as our resident Windows expert do you have any ideas what could be happening?

[am11]

msbuild win/libsass.sln

If you are sure that this MSBuild in PATH corresponds to version of VS you have installed (i.e. by running msbuild /version), then this command is sufficient to build LibSass in Debug configuration. Passing /p:Configuration=Release to the command will build the shared lib in Release configuration. You can also try by invoking MSBuild with absolute path as per the build doc: https://github.com/sass/libsass/blob/master/docs/build-with-visual-studio.md#from-powershell

If you are still having the same issue, then Google returns a following workaround for error code, TRK0005:
https://blogs.msdn.microsoft.com/deva/2015/03/24/after-migration-vs-2013-c-project-throws-error-trk0005-failed-to-locate-cl-exe-the-system-cannot-find-the-file-specified/

BTW, for the local build box to test out windows status etc.; if you don't want VS, you can just have Build Tools for VC installed to compile C/C++ projects strictly via command line -- with absolutely no glorious GUI: http://landinghub.visualstudio.com/visual-cpp-build-tools

[schneems]

Just getting to this comment now. I'm going to give this a shot. Thanks a ton! Will keep issue updated.

Also thanks for the windows support in the first place. It's a huge responsibility and the few times i've had to make windows compat patches makes me grateful for anyone who has experience there.

As a side note it looks like the makefile has some window specific code in it:

libsass/Makefile

Lines 26 to 42 in 6610e81

	ifneq (,$(findstring /cygdrive/,$(PATH)))
	UNAME := Cygwin
	else
	ifneq (,$(findstring Windows_NT,$(OS)))
	UNAME := Windows
	else
	ifneq (,$(findstring mingw32,$(MAKE)))
	UNAME := Windows
	else
	ifneq (,$(findstring MINGW32,$(shell uname -s)))
	UNAME = Windows
	else
	UNAME := $(shell uname -s)
	endif
	endif
	endif
	endif

did this file work with nmake at one time?

[am11]

Hello, regarding the side note: I think that code was meant for MinGW/Cygwin Makefile support and @mgreter can probably confirm it. nmake Makefile is a different entity and is most probably still shipped just to support the ancient projects. MSBuild was introduced as a "modern" build system, therefore we put effort to support that XML format.

We can probably switch to CMake at some point to encapsulate the underlying build systems. However, a handwritten Makefile and vcxproj files was preferred initially, but if it is causing effort for downstream consumers, we should look into CMake. @mgreter has put some major effort in the build system area.

I am on vacation and refraining myself to go near computers for six more days.. but yet here we are! 😄 I will try to catch-up with sprockets development and contribute. I used this gem back in the days with Rails 2x and glad to see it still standing tall. Thanks for your efforts @schneems! 👍

[schneems]

Hey, i'm trying to refrain from posting due to vacation (I really wish github had an OOO or Do not Disturb feature). Don't worry about replying while away.

Your advice was great and worked, also I found this doc https://github.com/sass/libsass/blob/master/docs/build-on-windows.md (way too late) which did re-confirm many things you've told me. I got a build working and I believe i've linked to it correctly using Ruby FFI interface, i'm now getting a segfault when I call into the lib. It could be a problem with the Ruby FFI interface, a problem with the sassc-ruby glue code, or a problem with the build of libsass into a dll.

I don't think you should need to know anything about Ruby, but maybe you could help with that last one. Is there any way for me to verify the dll I made works or is valid?

Let me know when you get back, hope you're enjoying time off.

[saper]

@schneems good to hear things are getting better. Thanks for providing all the information needed to troubleshoot this in your pull request - this is very useful. Can you try using MinGW toolkit to build libsass instead of Visual Studio? I've left the comment at the appropriate place.

[am11]

@schneems, I just found DevKit documentation: http://github.com/oneclick/rubyinstaller/wiki/Development-Kit and the fact that it is based on MinGW.

I then installed Ruby 2.3.0 and DevKit on my local VM, then added C:\tools\ruby23\devkit\bin and C:\tools\ruby23\devkit\mingw\bin in PATH.

After that, I applied the following diff on top of schneems/sassc-ruby@85ed673:

diff --git a/lib/sassc/native.rb b/lib/sassc/native.rb
index 261daba..b52b0c2 100644
--- a/lib/sassc/native.rb
+++ b/lib/sassc/native.rb
@@ -6,12 +6,7 @@ module SassC

     spec = Gem.loaded_specs["sassc"]
     gem_root = spec.gem_dir
-    if RUBY_PLATFORM =~ /mswin|mingw/
-      libsass_path = "#{gem_root}/ext/libsass/win/bin/libsass.dll"
-    else
-      libsass_path = "#{gem_root}/ext/libsass/lib/libsass.so"
-    end
-    ffi_lib libsass_path
+    ffi_lib "#{gem_root}/ext/libsass/lib/libsass.so"

     require_relative "native/sass_value"

diff --git a/lib/tasks/libsass.rb b/lib/tasks/libsass.rb
index 3542d8f..e439820 100644
--- a/lib/tasks/libsass.rb
+++ b/lib/tasks/libsass.rb
@@ -20,7 +20,7 @@ namespace :libsass do
     make_program = ENV['MAKE']
     make_program ||= case RUBY_PLATFORM
                      when /mswin|mingw/
-                       'msbuild /m:4 /p:Configuration=Release win/libsass.sln'
+                       'make lib/libsass.so'
                      when /(bsd|solaris)/
                        'gmake lib/libsass.so'
                      else

When I executed $CC="gcc" ; bundle exec rake test in PowerShell on Windows 10 x64, it passed:

Run options: --seed 1950

# Running:

********************************S*************************

Fabulous run in 0.174091s, 333.1591 runs/s, 539.9475 assertions/s.

58 runs, 94 assertions, 0 failures, 0 errors, 1 skips

I think your AppVeyor script would not need any alteration. Maybe you would need to add CC like this:

environment:
  global:
    CC: gcc
  matrix:
  ..

[mgreter]

@schneems does the info by @am11 above resolve your issue?

[schneems]

Sorry for the delay. I keep getting pulled away from this project. I'm going to close this for now so it doesn't clog up your issues. Thanks for the help. I hope to return to this soon.