Weird error MSB6006: "cmd.exe" exited with code 1 on some packages

[jviotti]

We've been facing a very strange issue at Etcher (https://github.com/resin-io/etcher). We have node-sass as a development dependency, and lzma-native as a production dependency.

When node-gyp was updated to v3.6.0, node-sass picked up this change, causing lzma-native to fail with the following error on Windows:

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code 1. [C:\projects\etcher\node_modules\lzma-native\build\liblzma.vcxproj]

So to make it clear, after the node-gyp upgrade on a development dependency (node-sass), a totally unrelated production dependency, lzma-native, suddenly starts to fail on Windows. What's even more strange is that node-sass compiles just fine, and removing node-sass from the development dependencies causes lzma-native to start working again. As a fix, we've started shrinkwrapping development dependencies as well, and locking node-gyp to v3.5.0, which makes everything work again.

The problem seems to have been introduced by ae141e1, however I don't understand why.

See balena-io/etcher#1191. You can probably reproduce by cloning Etcher, checking out a commit before such fix, and running make electron-develop (which is a Makefile target that we use to pass some node-gyp options to npm, run bower, etc).

[lurch]

The problem seems to have been introduced by ae141e1, however I don't understand why.

Hmm, I wonder if the problem might be that this part of the change:

  function findMsbuild () {
    if (config.variables.msbuild_path) {
      command = config.variables.msbuild_path

means that the MSBuild command is now run with its full-path "C:\Program Files (x86)\MSBuild\...\MSBuild.exe", whereas previously it was just run as MSBuild.exe, and this additional "C:\Program Files (x86)\MSBuild\..." is now just enough to push the lzma-native compilation command over the cmd.exe command-line length limit on Windows? http://stackoverflow.com/questions/3205027/maximum-length-of-command-line-string

[bnoordhuis]

cc @refack @joaocgreis

[refack]

hmmm... giving this some thought...

[refack]

It's not a "length of command line" issue, it's a "not run from VS console" issue.
The lzma-native build calls lib.exe which is not in the path unless vsvarsall.bat (or it's derivatives) is run.
Up till node-gyp:v3.5.x the whole thing would fail. Now we can find & call msbuild.exe in the general case, but than we fail if the build is complicated ;(

[refack]

Scratch that!
It's probably a bug in GYP. It erroneously escapes the action command...
from:

'action': [
  'lib -def:"<(module_root_dir)\\deps\\doc\\liblzma.def" -out:"<(module_root_dir)\\deps\\bin_x86-64\\lzma.lib" -machine:x64 && if not exist <(dlldir) mkdir <(dlldir) && copy "<(module_root_dir)\\deps\\bin_x86-64\\liblzma.dll" "<(dlldir)\\liblzma.dll"'
]

to: (extra " breaks cmd syntax)

call call "lib -def:"C:\code\3party\lzma-native\deps\doc\liblzma.def" -out:"C:\code\3party\lzma-native\deps\bin_x86-64\lzma.lib" -machine:x64 && if not exist C:\code\3party\lzma-native\binding-v2.0.0-node-v51-win32-x64 mkdir C:\code\3party\lzma-native\binding-v2.0.0-node-v51-win32-x64 && copy "C:\code\3party\lzma-native\deps\bin_x86-64\liblzma.dll" "C:\code\3party\lzma-native\binding-v2.0.0-node-v51-win32-x64\liblzma.dll""
if %errorlevel% neq 0 exit /b %errorlevel%

Instead of

call call lib -def:"C:\code\3party\lzma-native\deps\doc\liblzma.def" -out:"C:\code\3party\lzma-native\deps\bin_x86-64\lzma.lib" -machine:x64 && if not exist C:\code\3party\lzma-native\binding-v2.0.0-node-v51-win32-x64 mkdir C:\code\3party\lzma-native\binding-v2.0.0-node-v51-win32-x64 && copy "C:\code\3party\lzma-native\deps\bin_x86-64\liblzma.dll" "C:\code\3party\lzma-native\binding-v2.0.0-node-v51-win32-x64\liblzma.dll"
if %errorlevel% neq 0 exit /b %errorlevel%

[jviotti]

Awesome, great to hear you found the root cause of this issue! BTW, could you explain why in our case lzma-native started failing after node-gyp was upgraded by node-sass? I'm assuming that such upgrade caused lzma-native to start re-using node-sass's node-gyp version, which built node-sass fine, but caused errors on lzma-native because lzma-native uses lib.exe during build.

Is this correct?

[refack]

node-gyp come with npm. It's a tool that compiles "native bindings" for some modules.
Unfortunately native bindings need to be re-compiled for every version of node (or in this case electron).
lzma-native has an online cache of precompiled bindings, seems like the new version couldn't find a precompiled pack for your platform. In that case it tries to compile it with node-gyp which triggered the bug (bug might have been there for a while)

[addaleax]

@refack Yeah, but it’s still a curious thing how the node-sass upgrade made the difference?

[lurch]

I'm afraid I'll have to disagree with the (bug might have been there for a while) comment.
Up until 5 days ago all our Windows CI builds were working fine on Appveyor (including building lzma-native from source) but then all of a sudden (after the release of node-gyp 3.6.0) all our Windows CI builds started failing.

And our workaround for the problem in balena-io/etcher#1191 was to basically version-lock node-gyp to 3.5.0 which got everything working again.

[refack]

Up until 5 days ago all our Windows CI builds were working fine on Appveyor (including building lzma-native from source) but then all of a sudden (after the release of node-gyp 3.6.0) all our Windows CI builds started failing.

I said might... 🤷
I'm still digging...