Any news when stable 2.0 will be released?

[wintercounter]

Any news when 2.0 stable come out? Stable Libsass 3.1 is out now, and grunt-sass guys won't release their new version until node-sass isn't in stable. As you may know, Libsass 3.0, 3.1 has many improvements and fixes some blocker issues.

[am11]

It is coming 🔜 ™ :)

Actually we have some show stoppers (bugs) laying around
and trying hard to fix them. Once those are sorted out, we
will publish the binaries and release v2. Referring to #589.

[navneetgarg123]

The beta version currently doesn't work with mincer/connect-mincer. Just ends up with a 500 internal server error (using an express app). Down-graded to 1.2.3 - back in business.

[am11]

//cc @xzyfer, @mgreter, @kevva, @QuLogic,

I will be busy this week. If anyone has time, please prepare the Linux binary. I prepared both x86 and x64 binaries sass/node-sass-binaries#30, but when tested those on CentOS 5.5, I was getting the same GLIBCXX 3.4.9 issue all over again. I built those with gcc v4.6 on Ubuntu 12.04, that is the minimum version with which libsass v3.1.0 gets compiled (which doesn't require any code changes). So I thought using --static-libstdc++ flag would help, but unfortunately, it doesn't make any difference.

Here is the config.gypi and Makefile, which node-gyp builds using binding.gyp. I tried adding --static-libstdc++ on line 48 manually, but running make generates the ditto binary as without the flag. (not sure where to put the flag in binding.gyp, to emit it in Makefile).

@QuLogic, the fedora mock trick didn't work either, because libsass require some symbols which aren't available in older libstdc++, so I presume that the only correct way is to compile libsstdc++ statically.

[QuLogic]

With this answer, you can see what symbols require GLIBCXX 3.4.9. Maybe you can patch those functions to use syntax from older C++ and then it'd not link those newer symbols. I'm not sure if that's feasible though... It's possible that libsass uses enough new C++11 stuff to not be able to use those older libstdc++ at all.

[am11]

Previously, @mgreter made a patch for node-sass, which I had to apply manually to build the release via CentOS 5.5. Moving forward, this might not be a feasible option; as you have pointed out that down the road, libsass might be using more recent C++11/14 features.

I think we only have two options here (likeliness order: descending):

• Statically compile libstdc++ for which we need to (figure out how to) configure GYP. Theoretically, it should bundle and link all the missing symbols in old version of glibc, not sure how old? Having a switch in gcc like --minimum-lib <enter-version> would probably solve all the problems in the world...
• Patch every time before publishing a release: an increasingly non-viable option.

At present, we test the build to check if it throws then move on to manual build. But that doesn't make much sense because if the target does have recent version of gcc installed which can compile libsass (naturally with newer libcxx), chances are it would not fail the test in first place.

[xzyfer]

I can build linux binaries but I expect they'll have the issues as previous builds.

[am11]

@xzyfer, if you can figure out a way to rebuild libstdc++ statically, it would make the future releases super easy. :)

If that is technically not possible to compile libstdc++ statically for backward compatibility, then unfortunately we would have to drop the support for older targets, because simply put; nobody will revisit libsass and change code for older libstdc++ before every node-sass build.

This will be a deal breaker for masses (heroku and other cloud/web hosting services, who will probably take a decade to upgrade their systems); after all, this is nearly an impossible situation to manage (at least for me).

[xzyfer]

I've had no luck statically building libstdc++.

My 2c it's my understanding that older versions of linux have been an issue in previous releases. With that being the case I don't believe we should hold up this release any longer on it.

Hopefully in the future someone will put their hand up to get a compatible binding compiled, or at the very least actionable items for the Libsass team to consider.

[am11]

Edited:

I still think we should step back and give it another try. :)

Using -static and/or -static-libstdc++ (here, here and here) did not work. I tried all combinations and tested the binary on other distros. However, with one combination (using -static only) It was throwing a different exception that glibc 2.14 not found (since Ubuntu 12.04 and even v14 has older glibc than the old CentOS v5.5 !?!?!). So I made a U-turn. (I remember @mgreter mentioned it at some point that even if libc is statically linked, libstdc++ will cause a problem since it again depends on libc dynamically -- so lesson learned by hard way :D).

Going by this: http://stackoverflow.com/a/3214232/863980, I mkdired a libc/ directory in node-sass root directory (I know this will not be its final destination.. that would be somewhere in vendor directory -- only if it works out). then copied libc.so.6 and libstdc++.so.6 in it. Then I made the following change in binding.gyp:

--- a/binding.gyp
+++ b/binding.gyp
@@ -87,7 +87,13 @@
         ['OS!="win"', {
           'cflags_cc+': [
             '-std=c++0x'
-          ]
+          ],
+          'link_settings': {
+            'libraries': [
+                '../libc/libc.so.6',
+                '../libc/libstdc++.so.6'
+            ]
+          }
         }]
       ]
     }

When I did node-gyp configure, it emitted build/binding.target.mk with the following:

....
....
### Rules for final target.
LDFLAGS_Debug := \
        -pthread \
        -rdynamic \
        -m64

LDFLAGS_Release := \
        -pthread \
        -rdynamic \
        -m64

LIBS := \
        ../libc/libc.so.6 \
        ../libc/libstdc++.so.6
....
....

Subsequently I ran ldd build/Release/binding.node which outputted:

        linux-vdso.so.1 =>  (0x00007fffea3c7000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f1323f90000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f1323c8e000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f1323a77000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f132385b000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f132349a000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f1324612000)

and here is what I got from readelf -d build/Release/binding.node: https://gist.github.com/am11/e075d33f2bb7ab6e0cde.

Apparently it is still not linking with local libc/libc and libc/libstdc++, which the aforementioned SO answer suggests? Am I reading the readelf and ldd outputs correctly?

Update:

Here is the commit: 20f52b7.