-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Any news when stable 2.0 will be released? #602
Comments
It is coming 🔜 ™ :) Actually we have some show stoppers (bugs) laying around |
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. |
//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 Here is the config.gypi and Makefile, which node-gyp builds using binding.gyp. I tried adding @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. |
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. |
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):
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. |
I can build linux binaries but I expect they'll have the issues as previous builds. |
@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). |
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. |
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 Going by this: http://stackoverflow.com/a/3214232/863980, I --- 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 ....
....
### 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 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 Apparently it is still not linking with local libc/libc and libc/libstdc++, which the aforementioned SO answer suggests? Am I reading the Update: Here is the commit: 20f52b7. |
FWIW, I was conducting this exercise with bleeding-edge version of CentOS: |
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. |
@am11 You are still dynamically linked. The dynamic linker does not look in the current path; that would be a security risk.
This is probably what @am11 needs, since libsass appears to require a newer compiler than available on the desired oldest-supported distro. |
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 |
If you're getting |
Hey guys, thanks for the comments. I built the node binary with |
Out of curiosity, what is the current status on this? Is there an ETA at this point? |
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 |
@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 The minimum support for CentOS is v5.11 and that of Ubuntu is v12.04 LTS. |
I've looked into automated binary builds and generally speaking it seems Having dug some time into this my feeling is we're going to need to build
|
I believe the patch was made to Libsass to essentially unwind the cpp However (i believe) the latest Libsass is now using some backwards
|
Since all attempts failed, it is time to fallback to manual strategy. @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 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 |
We should continue to support 0.10 for the near future. Upgrading takes
|
@xzyfer, I agree. So we would have to support multiple |
👍 |
@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. |
@xzyfer would you be interested in the binaries being compiled on the CI automatically based on releases? |
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. |
@xzyfer I've got some spare time this coming week, probably 8 hours or so. Where would that time be wisely spent? |
@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. |
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. |
@austinpray we are tracking that issue at #56 (the oldest opened issue). |
Thanks @am11 |
* Locking down v2.0.0. Related Issue: sass#602.
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). |
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 |
Thanks for that gist @am11 |
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.
The text was updated successfully, but these errors were encountered: