Update CRC module to SSE4_CRC32 v3.1.0

[anandsuresh]

• v3.1.0 fixes issues with hardware CRC detection and provides software fallback
  for platforms lacking hardware CRC support.
• Reduces the number of layers between core code and the CRC functions
• Fixes illegal hardware instruction (core dumped) on importing gcloud #425

[ryanseys]

It seems that under Node v0.12.0 the package cannot be installed.

[anandsuresh]

Strange. The sse4_crc32 module passed all tests on node v0.10, 0.11 and 0.12. Is there something different about the environment that the CI system is running in?

I just built the module on my macbook running node v0.12.0.

anandsuresh@AnandSuresh-23981 sse4_crc32 (master) $ nvm install v0.12.0
######################################################################## 100.0%
Now using node v0.12.0
anandsuresh@AnandSuresh-23981 sse4_crc32 (master) $ node -v
v0.12.0
anandsuresh@AnandSuresh-23981 sse4_crc32 (master) $ make clean
./node_modules/.bin/node-gyp clean
gyp info it worked if it ends with ok
gyp info using node-gyp@1.0.3
gyp info using node@0.12.0 | darwin | x64
gyp info ok
anandsuresh@AnandSuresh-23981 sse4_crc32 (master) $ make
./node_modules/.bin/node-gyp clean
gyp info it worked if it ends with ok
gyp info using node-gyp@1.0.3
gyp info using node@0.12.0 | darwin | x64
gyp info ok
npm install .

> sse4_crc32@3.1.0 install /Users/anandsuresh/voxer-inc/sse4_crc32
> node-gyp rebuild

child_process: customFds option is deprecated, use stdio instead.
  CXX(target) Release/obj.target/sse4_crc32/src/sse4_crc32.o
  SOLINK_MODULE(target) Release/sse4_crc32.node
  SOLINK_MODULE(target) Release/sse4_crc32.node: Finished
./node_modules/.bin/node-gyp configure
gyp info it worked if it ends with ok
gyp info using node-gyp@1.0.3
gyp info using node@0.12.0 | darwin | x64
gyp info spawn python
gyp info spawn args [ '/Users/anandsuresh/voxer-inc/sse4_crc32/node_modules/node-gyp/gyp/gyp_main.py',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'make',
gyp info spawn args   '-I',
gyp info spawn args   '/Users/anandsuresh/voxer-inc/sse4_crc32/build/config.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/Users/anandsuresh/voxer-inc/sse4_crc32/common.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/Users/anandsuresh/voxer-inc/sse4_crc32/node_modules/node-gyp/addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/Users/anandsuresh/.node-gyp/0.12.0/common.gypi',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_root_dir=/Users/anandsuresh/.node-gyp/0.12.0',
gyp info spawn args   '-Dmodule_root_dir=/Users/anandsuresh/voxer-inc/sse4_crc32',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--no-parallel',
gyp info spawn args   '--generator-output',
gyp info spawn args   'build',
gyp info spawn args   '-Goutput_dir=.' ]
gyp info ok
./node_modules/.bin/node-gyp build
gyp info it worked if it ends with ok
gyp info using node-gyp@1.0.3
gyp info using node@0.12.0 | darwin | x64
gyp info spawn make
gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
make[1]: Nothing to be done for `all'.
gyp info ok
./node_modules/.bin/tap test/*.test.js
ok test/basic.test.js ................................... 4/4
total ................................................... 4/4

ok

[stephenplusplus]

Thanks for sending this in, @anandsuresh! I'm a little out of my wheelhouse trying to investigate this issue, but the 0.12 Travis error is:

Error: Module did not self-register.

Googling took me to an explanation of what that means: sass/node-sass#655 - maybe from their solution, one of you can make sense of how to fix for sse4_crc32?

[anandsuresh]

That's the result I landed up at as well. Have been trying to make sense of
it but no luck so far.

Might have to soon up a Linux VM and test it locally.
On Apr 20, 2015 7:20 AM, "Stephen Sawchuk" notifications@github.com wrote:

Thanks for sending this in, @anandsuresh https://github.com/anandsuresh!
I'm a little out of my wheelhouse trying to investigate this issue, but the 0.12
Travis error
https://travis-ci.org/GoogleCloudPlatform/gcloud-node/builds/57841134#L963
is:

Error: Module did not self-register.

Googling took me to an explanation of what that means: sass/node-sass#655
sass/node-sass#655 - maybe from their
solution, one of you can make sense of how to fix for sse4_crc32?

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

[ryanseys]

I emailed the folks at Travis describing our issue here and they replied with the following:

Thanks for the email. We are sorry to hear about the problem you are having. What sort of machine are you using for your development? Is it an Ubuntu machine running 64-bit kernel, or are there significant differences? Also, does the problem occur if you run the build on the standard infrastructure with sudo: required?

It appears that their boxes run on Ubuntu 64-bit. Perhaps we could try switching to the old infrastructure by setting sudo: required in our travis.yml

[ryanseys]

Update: https://travis-ci.org/ryanseys/gcloud-node/builds/60161412

No, sudo: required didn't help. I believe it's an issue with the module being incompatible with node 0.12.0 on certain machines. :(

[anandsuresh]

Will try building the module manually in an Ubuntu 12.x 64-bit VM and report back.

[ryanseys]

I booted into a Docker with Ubuntu 64-bit and installed Node 0.12.2, attempted to install sse4_crc32, giving me the following error:

root@bfe40e612555:/# npm install sse4_crc32
-
> sse4_crc32@3.1.0 install /node_modules/sse4_crc32
> node-gyp rebuild

gyp ERR! configure error
gyp ERR! stack Error: Can't find Python executable "python", you can set the PYTHON env variable.
gyp ERR! stack     at failNoPython (/usr/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:103:14)
gyp ERR! stack     at /usr/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:42:11
gyp ERR! stack     at F (/usr/lib/node_modules/npm/node_modules/which/which.js:40:25)
gyp ERR! stack     at E (/usr/lib/node_modules/npm/node_modules/which/which.js:43:29)
gyp ERR! stack     at /usr/lib/node_modules/npm/node_modules/which/which.js:54:16
gyp ERR! stack     at FSReqWrap.oncomplete (fs.js:95:15)
gyp ERR! System Linux 3.18.11-tinycore64
gyp ERR! command "node" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /node_modules/sse4_crc32
gyp ERR! node -v v0.12.2
gyp ERR! node-gyp -v v1.0.3
gyp ERR! not ok

So it seems at the very least we need Python installed to build this thing.

Edit: And make and g++. Then it finally built without errors. Never got the Error: Module did not self-register. error.

[anandsuresh]

Aah! Python is a node-gyp dependency. Maybe someday we can build node-addons without node-gyp and python. But until then...

So it seems more like a test environment issue.

[ryanseys]

Hmm, I actually don't think that's an issue really. It seems to have nothing to do with the Module did not self register. error. I'm curious if pre-built binaries were provided for the test environment it would get rid of the issue. I'd imagine that's difficult to do though.

[anandsuresh]

Oh. I see what you mean. Having taken a peek at the Travis logs, it seems that the module builds correctly when the npm install step is executed. So I'm not sure why that error pops up. I have had no luck reproducing that error at my end.

Googling the issue brings up some other modules that faced similar problems, but those were resolved by deleting the node_modules directory and reinstalling the module. Doesn't seem like that solution would help in this case.

Yet another analysis mentioned that this might be caused due to inconsistencies in node-gyp and/or npm due to a botched install that did not complete successfully, and/or failed to clean up files from older versions. Perhaps the image being used by the Travis CI system suffers from that issue. No real way to verify that though.

The SSE4_CRC32 module itself uses Travis CI, without any problems on node versions 0.10, 0.11 and 0.12.

[anandsuresh]

Also, if it helps, here are the environments where I've tested the SSE4_CC32 module to be working:

• MacOS 10.9.5
• SmartOS 5.11
• CentOS 6.6
• FreeBSD 10.0

[ryanseys]

Yes I'm looking further and it appears it might be an issue with the way we are using mockery, one of the test libraries we are using.

[dickfickling]

@ryanseys Could you push a new release to npm with this fix?

[ryanseys]

@richardfickling I'll do my best to get 0.14.0 pushed to npm in the near future.

[ryanseys]

@richardfickling A new version has been pushed if you didn't realize :)

[dickfickling]

Thanks @ryanseys 👍