Error: Module did not self-register. with Node 0.12 installed
Closed this issue · 42 comments
Error: Module did not self-register.
at Error (native)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)
at require (module.js:384:17)
at Object. (/vagrant/uil/node_modules/node-sass/lib/index.js:211:15)
at Module._compile (module.js:460:26)
at Object.Module._extensions..js (module.js:478:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
Makefile:50: recipe for target 'debug' failed
make: *** [debug] Error 1
node.js v0.12 (which was released 22 hours ago) will be supported by node-sass' next version v2.0.0.
any idea for a release date of version v2.0.0 ?
Note that was 2.0.0 beta
@sjonnet19, yes whenever the NODE_MODULE_VERSION changes, it require recompilation of binaries. See #627 (comment). That said; you can always manually build the binary (or by setting SKIP_SASS_BINARY_DOWNLOAD_FOR_CI environment variable to true before npm install node-sass <- given you have all the required tools installed).
👍 running into this on https://github.com/marionettejs/marionettejs.com
oh kewl... look there all the time and missed that sorry.
+1 Same issue on node v0.12.0
+1.....
+1
+1
BTW, with current state of master, you can build the binary by yourself for node-sass .12 or io.js:
git clone https://github.com/sass/node-sass --recursive
cd node-sass
git submodule update --init --recursive
npm install
node node_modules/pangyp/bin/node-gyp rebuild -f
# or:
iojs node_modules/pangyp/bin/node-gyp rebuild -f(Optionally you can configure before build: node node_modules/pangyp/bin/node-gyp configure .. then build or rebuild)
@am11 thanks for the tip.
Installing node v.0.10 with nvm is a quick fix for those of you stuck on this issue.
I'd say if you have a (production) team depending on this module wait until the 0.12-compatible release is out. That should be the easiest way to handle that problem.
If I was really keen to use 0.12, then I'd take a look at putting the commands into a shell script and using npm's scripting options. But I would not recommend that.
Thanks. My team is using homebrew to install node on OSX and I've suggested to them not to run "homebrew upgrade" because that will give them 0.12.
Should be able to hold off.
Am I wrong (without arguing iojs), or should this release of node be a X.0.0 upgrade instead of 0.X.0 since it's breaking packages? Or do they not at all use semver ?
@framerate, we are preparing for vNext. It will be available real soon.
npm install node-sass@2.0.0 is released!
Checkout the release notes: https://github.com/sass/node-sass/releases/tag/v2.0.0
@am11
So does it still work with node 0.10.x line? We will be transitioning providers but until then we're stuck with 0.10.x and we need to know if we should go bug other projects that use node-sass in their deps and freeze ours for the time being if not.
@Martii yes (as mentioned in the release notes).
Also, checkout the coverage matrix in node-sass-binaries release: https://github.com/sass/node-sass-binaries/releases/tag/v2.0.0
@am11
Thanks for adding that in just now. :) Just noticed you do have it mentioned at /sass/node-sass/blob/dc3a77/package.json ... very kewl.
@Martii, yeah I drafted it at two places. Just finished assembling all the pieces. :)
@am11 I'm still getting Error: Module did not self-register. with when attempting to npm install node-sass@2.0.0 with both iojs-1.2.0 and node 0.12.
same error when install V2.0.0 node 0.12.0
`darwin-x64-node-0.12` exists; testing
module.js:355
Module._extensions[extension](this, filename);
^
Error: Module did not self-register.
I've confirmed this error on 2.0.0. It should be addressed in 2.0.1
Hmm now this is odd... using checkout and compiled locally of https://github.com/joyent/node/tree/v0.12.0-release:
$ npm install node-sass@2.0.0
/
> node-sass@2.0.0 install /home/user/repo/git/oujs/martii/test/node_modules/node-sass
> node scripts/install.js
> node-sass@2.0.0 postinstall /home/user/repo/git/oujs/martii/test/node_modules/node-sass
> node scripts/build.js
`linux-x64-node-0.12` exists; testing
Binary is fine; exiting
node-sass@2.0.0 node_modules/node-sass
├── get-stdin@4.0.1
├── object-assign@2.0.0
├── replace-ext@0.0.1
├── nan@1.6.2
├── semver@4.2.2
├── shelljs@0.3.0
├── cross-spawn@0.2.6 (lru-cache@2.5.0)
├── mkdirp@0.5.0 (minimist@0.0.8)
├── chalk@0.5.1 (escape-string-regexp@1.0.2, ansi-styles@1.1.0, supports-color@0.2.0, strip-ansi@0.3.0, has-ansi@0.1.0)
├── npmconf@2.1.1 (uid-number@0.0.5, inherits@2.0.1, osenv@0.1.0, ini@1.3.3, once@1.3.1, config-chain@1.1.8, nopt@3.0.1)
├── meow@3.0.0 (minimist@1.1.0, camelcase-keys@1.0.0, indent-string@1.2.0)
├── gaze@0.5.1 (globule@0.1.0)
├── mocha@2.1.0 (escape-string-regexp@1.0.2, diff@1.0.8, growl@1.8.1, commander@2.3.0, jade@0.26.3, debug@2.0.0, glob@3.2.3)
├── request@2.53.0 (caseless@0.9.0, json-stringify-safe@5.0.0, forever-agent@0.5.2, aws-sign2@0.5.0, stringstream@0.0.4, oauth-sign@0.6.0, tunnel-agent@0.4.0, isstream@0.1.1, node-uuid@1.4.2, qs@2.3.3, combined-stream@0.0.7, form-data@0.2.0, mime-types@2.0.9, http-signature@0.10.1, tough-cookie@0.12.1, bl@0.9.4, hawk@2.3.1)
└── sass-graph@1.0.3 (commander@2.6.0, lodash@2.4.1, glob@4.3.5)Yeah there was an issue with the binaries we generated for osx. They've since been updated. Checking out master would have given you fixes to fetch the correct binaries.
Well this is a Linux system not Darwin... so I think I got the correct binary... just thought I'd double check on this end with my distro. Unfortunately my PPC was my last Mac and it hasn't been replaced yet. ;) (if you haven't guessed it I'm a tester at heart)
Ah cool. There a second problem where weren't normalising the path we fetch the binary from. We didn't account for *nix returning nodejs where osx and windows return node. So *nix installs were failing to pull the binding and potentially breaking installs.
@xzyfer, thanks for the quick fixes!
v2.0.1 is published with the fixes.
npm install node-sass@2.0.1The issue seems to be appearing again with 2.1.1 and node.js 0.12.X.
When I downgraded node.js version to 0.10.38 - it started working fine. Any thoughts on how to resolve this issue with latest node version/io.js?
@jskungfu I've been using node-sass successfully on 2.1.1 and 0.12.2. Have you tried clearing out node_modules and reinstalling?
@caseywebdev
I should have mentioned it with my original comment but I am mentioning it is now that I am using this as node module in my grunt watch task and it is working when first file change is noticed. After first successful compilation it starts giving me this error on consecutive compilations.
I tried to use all of above tricks that is mentioned above but it is not working with node 0.12.2 but when I switch back to node version 0.10.38, it works flawless with every file change compilations.
@jskungfu can you please create a new folder in ~/tmp. Run npm install@2.1.1 and confirm the issue still exists?
Please also supply us with your OS, OS version, and the output ./node_modules/.bin/node-sass --version.
As for your watching issues, that needs to be opened with the grunt-sass project.
for me it resolved after 'npm rebuild'
Hi
I have a same issue when i run ./licode/scripts/initLicode.sh a log file is generated with bellow error
and in browser console i got message
...
DEBUG: Event: room-connected
erizo.js:161 ERROR: Error when publishing the stream: No ErizoAgents available
module.js:356
Module._extensions[extension](this, filename);
^
Error: liberizo.so: cannot open shared object file: No such file or directory
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object. (/opt/licode/erizo_controller/erizoJS/erizoJSController.js:3:13)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)
Please any one help me
Try : npm install --update-binary . It worked for me.