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.

[am11]

FWIW, I was conducting this exercise with bleeding-edge version of CentOS: 7.0.1406 (Core)
(with gcc / g++ v4.8.2) and testing on Ubuntu v12.0.4 (vagrant precise64 box) and CentOS 5.5 x64.

[rvagg]

Sorry for not having full context here, but if you're releasing binaries then you should do it on the oldest version of linux you want to support so you have minimum libc. For the node and io.js linux distributable binaries, they are built on CentOS 5 so they are compatible with that and everything newer. For io.js we have a minimum gcc 4.8 requirement which makes it tricky but we're able to pull in the devtoolset-2 toolchain from CERN to do the compiling and not upgrade the libc. If you want any of the gory details they are all here in the Ansible playbook: https://github.com/iojs/build/tree/master/setup/centos5

IMO you shouldn't need to distribute or pin to a particular minim libc if this is only for distributing binaries.

[QuLogic]

@am11 You are still dynamically linked. The dynamic linker does not look in the current path; that would be a security risk.

For io.js we have a minimum gcc 4.8 requirement which makes it tricky but we're able to pull in the devtoolset-2 toolchain from CERN to do the compiling and not upgrade the libc

This is probably what @am11 needs, since libsass appears to require a newer compiler than available on the desired oldest-supported distro.

[rvagg]

this is all done on digitalocean btw, so you could probably fire up a $5 box to do it on easily enough. Note the awkward step in startup.sh though, you have to start builds (or a bash session) with scl enable devtoolset-2 <something> and then everything is properly set up to in that session for the new toolchain.

[QuLogic]

If you're getting devtoolset-2 from a repo, you should be able to do it in mock locally...

[am11]

Hey guys, thanks for the comments. I built the node binary with devtoolset-2 on CentOS 5.11, but it failed on Ubuntu 12.04.4 with: version```GLIBCXX_3.4.18' not found.

[KittyGiraudel]

Out of curiosity, what is the current status on this? Is there an ETA at this point?

[mattclements]

What's the current progression on this and I'll see if I can lend a hand! Thinking of a Vagrant setup to automate the builds

[am11]

@mattclements, great! Our primary objective is to make sure that both x86 and x64 binaries are working in other distros, expecially CentOS and Ubuntu, so the users are not required to upgrade anything on their system before executing npm install node-sass.

The minimum support for CentOS is v5.11 and that of Ubuntu is v12.04 LTS.

[xzyfer]

I've looked into automated binary builds and generally speaking it seems
straight forward. It however doesn't solve the centos issue.

Having dug some time into this my feeling is we're going to need to build
separate binaries for centos and make adjustments to the install scripts.
On 1 Feb 2015 18:23, "Adeel Mujahid" notifications@github.com wrote:

@mattclements https://github.com/mattclements, great! Our primary
objective is to make sure that both x86 and x64 binaries are working in
other distros, expecially CentOS and Ubuntu, so the user do not have to
upgrade anything on executing npm install node-sass.

The minimum support for CentOS can be 5.11 and that of Ubuntu is 12.04 LTS.

—
Reply to this email directly or view it on GitHub
#602 (comment).

[mattclements]

Thanks @am11 & @xzyfer - Does anyone have any details as to how they built these on CentOS5 - I understand there was a patch required etc

[xzyfer]

I believe the patch was made to Libsass to essentially unwind the cpp
11syntactic sugar. I don't know the specifics /cc @am11

However (i believe) the latest Libsass is now using some backwards
incompatible cpp 11 features so this approach may not be feasible any more.
On 1 Feb 2015 20:36, "Matt Clements" notifications@github.com wrote:

Thanks @am11 https://github.com/am11 & @xzyfer
https://github.com/xzyfer - Does anyone have any details as to how they
built these on CentOS5 - I understand there was a patch required etc

—
Reply to this email directly or view it on GitHub
#602 (comment).

[mgreter]

https://github.com/mgreter/libsass/commits/test/gcc-4.4

[am11]

Since all attempts failed, it is time to fallback to manual strategy.
I will build the binaries with @mgreter's patch again.
Hopefully someone with better build system knowledge will contribute a tangible solution here.

@xzyfer, @kevva, should we drop the support for node v0.10 branch, since v0.12 stable is released today/25-hours-ago (and we are currently only aiming to only distribute binaries for production-ready version of node.js)? Going by this: #627 (comment), it is not possible to build binary which works across various NODE_MODULE_VERSION.

Or should we break the habit and make both sets of binaries available for v0.10 and v0.12 (which would require some extra plumbing in our build and install scripts)? So it will have linux-x64-node-0.10/binding.node and linux-x64-0.12/binding.node etc. for all architectures..

[xzyfer]

We should continue to support 0.10 for the near future. Upgrading takes
time and the changes in 0.12 are significant. I guess is adoption of the
new version will take some time.
On 8 Feb 2015 10:27, "Adeel Mujahid" notifications@github.com wrote:

Since all attempts failed, it is time to fallback to manual strategy.
I will build the binaries with @mgreter https://github.com/mgreter's
patch again.
Hopefully someone with better build system knowledge will contribute a
tangible solution here.

@xzyfer https://github.com/xzyfer, @kevva https://github.com/kevva,
should we drop the support for node v0.10 branch, since v0.12 stable is
released today/25-hours-ago (and we are currently only aiming to only
distribute binaries for production-ready version of node.js)? Going by
this: #627 (comment)
#627 (comment), it
is not possible to build binary which works across various
NODE_MODULE_VERSION.

Or should we break the habit and make both sets of binaries available for
v0.10 and v0.12 (which would require some extra plumbing in our build and
install scripts)? So it will have linux-x64-node-0.10/binding.node and
linux-x64-0.12/binding.node etc. for all architectures..

—
Reply to this email directly or view it on GitHub
#602 (comment).

[am11]

@xzyfer, I agree. So we would have to support multiple process.platform (Linux, Mac, Win) x process.arch (ia32, x64) x runtimes (atom-shell, iojs, node) x NODE_MODULE_VERSION (for each runtime's version we are going to support). And adding the future plan of supporting Solaris and FreeBSD to the mix is indeed going to bring about real pain without node-pre-gyp's automation.

[xzyfer]

👍

[xzyfer]

@am11 can you put together a list of all the binaries we need, and I'll start cranking them out. Assuming you've applied the Libsass patch ofcause.

[austinpray]

@xzyfer would you be interested in the binaries being compiled on the CI automatically based on releases?

[xzyfer]

This is certainly the plan moving forward @austinpray . However this release is well past due so I'd prefer to just get it out asap.

[austinpray]

@xzyfer I've got some spare time this coming week, probably 8 hours or so. Where would that time be wisely spent?

[xzyfer]

@austinpray there are two approaches for building an array or prebuilt binaries, either https://www.npmjs.com/package/node-pre-gyp, or tweaking the current build scripts to have CI generate the binaries and open PR using the GH APIs.

[xzyfer]

If you've got some time we'd appreciate some research into if/how we could go about using https://www.npmjs.com/package/node-pre-gyp to build our binaries automagically.

[am11]

@austinpray we are tracking that issue at #56 (the oldest opened issue).

[am11]

@xzyfer FYI #655 😎

[xzyfer]

Thanks @am11

[am11]

v2.0.0 is released.

npm install node-sass@2.0.0

Checkout the release notes: https://github.com/sass/node-sass/releases/tag/v2.0.0.

Also checkout the binary coverage matrix in node-sass-binaries release notes: https://github.com/sass/node-sass-binaries/releases/tag/v2.0.0 (a subset of matrix that can be found here: #655).

[am11]

Here is the gist recipe to build Linux release in CentOS v5.11-x64: https://gist.github.com/am11/6795fb5a8934859346ee (it is mostly up-to-date, unless I missed a step or two).

//cc @xzyfer

[xzyfer]

Thanks for that gist @am11