Version 1.0.6 requires a rebuild during npm install

[j3gb3rt]

On Windows 7 x64 with 32-bit node 0.10.26, during the install it states:

`win32-ia32-v8-3.14` exists; testing
Problem with the binary; manual build incoming

I was also required to copy node.exe into the same folder and rename the copy to nodejs.exe becuase of this line

node build.js || nodejs build.js

Not sure of it's source file or if it may actually be part of node-gyp

[sjmcdowall]

Same issue ! Then it couldn't compile because I don't have a full dev. environment. :(

BTW -- not sure why you had to rename node.exe to nodejs.exe -- that line should execute "node build.js" first and if it does (or tries) only then does it try to run nodejs.exe. As long as you have a valid "node" in the path your ok -- it will just generate a fake error at the end about nodejs.exe not being there -- but it's already failed once .. would just fail again ..

[sjmcdowall]

Not sure if this helps -- but I manually ran the quick-test on 1.0.6 on my Windows 7 machine w/ node # 0.10.36 and here is the result:

$ node quick-test

module.js:356
Module._extensions[extension](this, filename);
^
Error: The system cannot find message text for message number 0x%1 in the message file for %
c:\Users\Steven McDowall\work\fibers\1.0.6\package\bin\win32-x64-v8-3.14\fibers.node
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. (c:\Users\Steven McDowall\work\fibers\1.0.6\package\fibers.js:20:3
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)

[laverdet]

Lol that error message is not helpful at all. Worth mentioning though is that it's not hard at all to setup a dev environment. Visual Studio Express is free, and besides that all you need is Python (and the Windows x64 SDK, which is also free).

[sjmcdowall]

yeah -- I didn't think that message was going to be helpful. . Good to know about the dev environment though! I'll have to give it a shot .. luckily it's fibers@1.0.5 I really need and that works. :)

[BobDickinson]

I'm having the same problem. It's not quite as simple as "just set up a dev environment" because our package which requires fibers is installed by end users who aren't going to necessarily have the skills or desire to do that. So we've been relying on the bundled binaries working out of the box (which they did before 1.0.6).

I tried to track this down by doing a force install so I could get the file set and run quick-test on them. When I do that, I get:

node quick-test.js

module.js:356
Module._extensions[extension](this, filename);
^
Error: A dynamic link library (DLL) initialization routine failed.
C:\Dev\Test\node_modules\fibers\bin\win32-x64-v8-3.14\fibers.node
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. (C:\Dev\Test\Bob\node_modules\fibers\fibers.js:20:37)
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)

So that's also not helpful (it's basically just saying that the DLL didn't load for some reason, which I think we already knew was the case).

[BobDickinson]

I decided to just use npm-shrinkwrap and force 1.0.5 as a workaround (we're trying to push our own release ASAP). This of course caused a whole series of issues on other platforms - 1.0.5 requires a build on iOS, which throws some warnings, fails to build on Ubuntu due to node vs nodejs script issue, etc. Those issues are documented and fixed in 1.0.6 of course (I probably should have researched the 1.0.5 issues before rolling back).

We've been assuming that we'd be able to rely on pre-built binaries (at least for those platforms not likely to have build environments installed - especially Windows). Setting up a build environment to get fibers to work is also problematic for a common scenario we have, which is deploying a cloud service to Azure via the MSFT tools (it might be technically possible to use PowerShell to install the required tools and set up the environment every time, just in case it's needed, but that doesn't sound like fun).

I'm on Windows 10, node 0.10.32. I'd be happy to help figure out what's going on, but not sure quite where to start.

[sjmcdowall]

I'm probably barking up the wrong tree here -- but fibers is only pre-build on specific node versions. I don't think 010.32 is one, but 0.10.36 certainly is. Have you tried nvm and then install node 0.10.36 and give it a go?

[laverdet]

I published 1.0.7 just now with rebuilt binaries for 0.10.36, could you try again? Keep in mind in the next version of fibers 0.10.x will no longer support binary releases.

Additionally if you're sending this to clients it's downright irresponsible to not use shrinkwrap, so you should be doing that from the start anyway.

Also I accidentally unpublished 1.0.6 and I guess you can't undo that.

[BobDickinson]

I just installed 1.0.7 in my env and the pre-built binary was "is fine". Thanks much.

Also, I'm on 0.10.32, not 0.10.36, and it still worked. How does the targeting of the binary to node work in terms of what versions of node are supported by a given binary? I'm guessing you build for what's contemporary at the time, and the test on install is how we know if it doesn't bind (because the node version is too old or too new). I knew about having to match up to the v8 version, but I guess I didn't understand that there were linking constraints beyond that that were dependent on the node binary (if that is the case).

Will binaries be supported on 0.12.x going forward?

Roger on shrinkwrap. We're kind of new to distributing stuff in the node world.

[laverdet]

In the past I would release for the current and previous versions of node. Then iojs came and I added support for the latest version of that as well. Those all were built for Linux, OS X, and Windows on both ia32 and x64 architectures. All counted there were 18 binaries that needed to be built on each release of either node, iojs, or fibers.

node and iojs have finally finished merging as of 2 days ago (9/8) so the next publish of fibers will include binaries for only node v4.0.0. When node v5.0.0 is cut (scheduled for April) I'll support both v4 + v5, and then continue supporting the current and previous versions moving forward (so only 12 binaries total). That's assuming they don't upgrade v8 versions on minor releases which would substantially complicate things, but I don't foresee that happening.

Short answer: don't expect long-term support in the form of binaries for v0.12.x.

(note that in my last comment I was unaware the merging of node + iojs was complete, after learning that I adjusted my support plan a little).