node-pre-gyp: node-pre-gyp Appveyor build failing for Windows x86 using Node 4.4.3
I was having trouble building for Windows x86 using Node.js 4.4.3, when I noticed that the Appveyor build for node-pre-gyp itself is failing for the same reason:
ENOENT: no such file or directory in readCAFile
The failed build can be seen here:
https://ci.appveyor.com/project/Mapbox/node-pre-gyp/build/1.0.373/job/h12w3ymhbyg6ltq6#L481
The build for Windows x64 using Node 4.4.3 succeeds, however.
I see that the node-gyp command is failing, but I thought perhaps node-pre-gyp might be missing something for the setup for the 4.4.3 release.
Any thoughts as to what is missing here? Now that 4.4.3 is the LTS version, it would be great to be able to have nice precompiled binaries for it.
Thank you!
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 16 (10 by maintainers)
Commits related to this issue
- set fake 'cafile' argument for node@4.4.7 https://github.com/mapbox/node-pre-gyp/issues/209#issuecomment-217690537 — committed to mapbox/node-pre-gyp by wilhelmberg 8 years ago
- attempt to workaround mapbox/node-pre-gyp#209 — committed to naturalatlas/node-gdal by deleted user 8 years ago
- AppVeyor: HACK try to workaround node@4.x x64 'undefined' build failures refs https://github.com/mapbox/node-pre-gyp/issues/209#issuecomment-217690537 — committed to mapnik/node-mapnik by wilhelmberg 7 years ago
- workaround node v4 x86 problem - refs mapbox/node-pre-gyp#209 — committed to mapnik/node-mapnik by deleted user 7 years ago
- add back workaround for #209 — committed to mapbox/node-pre-gyp by deleted user 7 years ago
- also try dodging #209 via node-gyp upgrade — committed to mapbox/node-pre-gyp by deleted user 7 years ago
- add more comments to appveyor workarounds for #300 and #209 — committed to mapbox/node-pre-gyp by deleted user 7 years ago
- Enable 32 and 64 bit builds on Windows, disable Node version 4 Appveyor has a problem with Node 4 32 bit, for details see https://github.com/mapbox/node-pre-gyp/issues/209. — committed to gagern/node-libtidy by gagern 7 years ago
- add back workaround for #209 — committed to mapbox/node-pre-gyp by deleted user 7 years ago
- also try dodging #209 via node-gyp upgrade — committed to mapbox/node-pre-gyp by deleted user 7 years ago
- add more comments to appveyor workarounds for #300 and #209 — committed to mapbox/node-pre-gyp by deleted user 7 years ago
- appveyor should now pass after mapbox/node-pre-gyp#209 was fixed — committed to mapbox/node-pre-gyp by springmeyer 6 years ago
- add back workaround for #209 — committed to X-Profiler/node-pre-gyp by deleted user 7 years ago
- also try dodging #209 via node-gyp upgrade — committed to X-Profiler/node-pre-gyp by deleted user 7 years ago
- add more comments to appveyor workarounds for #300 and #209 — committed to X-Profiler/node-pre-gyp by deleted user 7 years ago
- appveyor should now pass after mapbox/node-pre-gyp#209 was fixed — committed to X-Profiler/node-pre-gyp by springmeyer 6 years ago
Hm, this is getting stranger.
The error is intermittent, sometimes it occurs and sometimes it does not.
I’ve only been able to reproduce it with
npm testwhich sometimes errors like on AppVeyor (sometimes not):If I run the same command
directly from the command line it always succeeds:
My current hunch is that the problem just occurs with the tests and not with
node-pre-gyp/node-gyp/gypper se, asmochashells out tonode-pre-gypwhich shells out topre-gypwhich shells out togyp.I think somewhere on the way the environment gets screwed (sometimes, don’t know yet when and why) and thus results in failures.
This
shelling-outstructure also makes this problem a nightmare to debug: If I attach to and step through themochaprocess I cannot continue to step intonode-pre-gypwhen it gets executed. Same if I attach tonode-pre-gypandpre-gypgets called, and so on.I’ve got a two step work around and I filed a bug with node-gyp.
The error we see is that the string
undefinedisn’t a file. I’m only seeing this on 32bit windows machines with node 4.3 and 4.4. I haven’t checked others.The work around is to set the
cafileoption to a real file, I chosepackage.json. Then we get a second bug where even though it hasn’t found a cert in package.json it still tries to use one. So you have to disablestrict-ssl. We get some warnings but it works and doesn’t seem to affect other node versions.I added these to install phase in
appveyor.ymlProgress update
Downgrading to
node-gyp@3.2.1is not feasible as it fails with this error when building withVS 2015 Update 3(fixed innode-gyp@3.4.0):If this error still occurs after
npm install -g node-gyp@3.4.0a workaround might be to manually upgradenode-gypwithinnpm.Still searching where
undefinedis coming from …