Incorrectly building dynamic library on Windows

[Coridyn]

In the Makefile on Windows the UNAME variable gets the value Windows instead of MinGW

This causes the MinGW library check to fail and it builds a dynamic library on windows instead of a static lib:

# enable mandatory flag
ifeq (MinGW,$(UNAME))
    ifneq ($(BUILD),shared)
        STATIC_ALL     ?= 1
    endif
    STATIC_LIBGCC    ?= 1
    STATIC_LIBSTDCPP ?= 1
    CXXFLAGS += -std=gnu++0x
    LDFLAGS  += -std=gnu++0x
else
    STATIC_ALL       ?= 0
    STATIC_LIBGCC    ?= 0
    STATIC_LIBSTDCPP ?= 0
    CXXFLAGS += -std=c++0x
    LDFLAGS  += -std=c++0x
endif

Related to this issue: sass/sassc-ruby#18

[xzyfer]

@am11 @saper would love your input here

[saper]

The logic in https://github.com/sass/libsass/blob/3.3.2/Makefile#L24 seems to be pretty unreliable to me. I was only using Visual Studio to build libsass, so I didn't check that. @Coridyn are you using MinGW 64 to build? What is the value of MAKE during your build?

[Coridyn]

I'm using MinGW32 from the ruby devkit environment (Ruby 2.2.3p173 with DevKit mingw64-32-4.7.2).

I don't think it's that though - the first check for Windows is matching so it doesn't fall through to the MinGW cases at all.

Line 23 of the Makefile has the Windows check:

ifneq (,$(findstring WINDOWS,$(PATH)))
    # Matches here because "WINDOWS" is in the PATH variable
    UNAME := Windows
else
    # Doesn't get here because it's already detected as "Windows"
    ifneq (,$(findstring mingw32,$(MAKE)))
        UNAME := MinGW
    else
        # This `uname` check would work if it reached this far.
        ifneq (,$(findstring MINGW32,$(shell uname -s)))
            UNAME = MinGW
        else
            UNAME := $(shell uname -s)
        endif
    endif
endif

[am11]

Perhaps Windows should be detected with:

// source: http://stackoverflow.com/a/12099167/863980

ifeq ($(OS),Windows_NT)
// Windows
else
// Unix
end

[saper]

I don't really know what this check is for. Visual Studio will not use that Makefile, you rule out cygwin earlier, is this a fallback case for "neither VS, nor cygwin, nor MinGW"? I think we should just remove this check.

[saper]

This was added in e088cc3 for Appveyor integration, and later f9f51f8 and 0c072dd added the MinGW check @mgreter do we really need that "Windows" check?

[mgreter]

The compiler is not the important part here, but the used make utility and the shell. I think I have once tested it with: mingw32-make, make and dmake. Either in cmd.com, msys and cygwin shell. Finally compiler can also differ from native gcc on windows via cygwin, mingw32, clang, etc. I tried to apply some educated guesses what to expect under which circumstances. I suspect that this removal may be the culprit here. But it was probably removed because it broke something else. Maybe we just need to change the order of the detection.

We will not be able to support all combinations with one native makefile. For that reason we also provide autotools build files, which can be used via cygwin (although cmake would be nicer on the windows side).

[mgreter]

Should hopefully be fixed by #1882

[mgreter]

I merged #1882, please re-open if problem persists.