Pkg: Warning Failed to make bytecode for file

[Deilan]

Trying to package an app with just --targets node8.6.0-win-x86 in linux. Get dozens of warnings:
Warning Failed to make bytecode for file C:\snapshot\app\index.js error (spawn /home/travis/.pkg-cache/v2.3/fetched-v8.6.0-linux-x86 ENOENT).

The resulting app doesn't work on Windows.

If i enable --no-bytecode, I get:

Error! --no-bytecode and no source breaks final executable
/home/travis/build/app/index.js
Please run with "-d" and without "--no-bytecode" first, and make
sure that debug log does not contain "was included as bytecode".

With the option disabled and -d enabled I get around one hundred lines with [debug] The file was included as bytecode (no sources) in the logs.

If I launch the same packaging process in macOS, it works fine.

Both [email protected] or [email protected].

[adonespitogo]

Using [email protected] - I also get many errors > Warning Failed to make bytecode node8.0.0-armv7 for file /snapshot/piso-wifi/node_modules/engine.io-client/node_modules/ws/lib/BufferUtil.fallback.js error (read ECONNRESET) when trying to compile with --targets node8.0.0-linux-armv7

I'm on arch linux

[niicojs]

I got the same trying to build for windows x86 from travis

[adonespitogo]

@zeit If you can let us know where to start looking into this issue, I'd be very much happy to help fix this.

[itai-codefresh]

This is really a blocker for me too.
Our CI generates the binaries and it is currently broken.
Any workaround until the fix would be appreciated.

[niicojs]

As a workaround, you can use a ci tool based on windows (like appveyor) which doesn't have the problem. It's free for open source so that works for me in the meantime.

[Deilan]

Continuing @niicojs's note. If in your case Travis CI is a must, consider switching from linux vm or container to macos vm, which works pretty fine. We've done this in our project.

Pros: pretty little changes towards already existing build workflow.
Cons: the macos vm starts up much longer than the linux container.

[niicojs]

good point
for now, I've kept everything else in travis/linux and moved packaging only to appveyor so I keep travis fast (which is good) and move packaging (which can be slower) elsewhere

[egoroof]

Have the same problem.
As our private CI is only on linux so we go this way: bundle all js files (include node_modules) into single one (through webpack) and deploy this bundle with nodejs binary from official website (like https://nodejs.org/dist/v8.9.4/win-x86/node.exe). So it's now 2 files instead of 1 and we don't need to build any binaries. Maybe it help someone.

[mjackson]

I ran into this same issue today trying to build react-stdio for x86 on Windows and Linux, using pkg 4.3.0.

[huerlisi]

I experienced the same issue on GitLab CI. But I was able to build them locally. The solution was to include support for 32-bit executables.

I'm using the node:7 image on GitLab CI as build image. The runners are on a 64-bit host. When debugging locally using docker run -it -v $PWD:/root/vdds-client node:7 /bin/bash I found out that I had the same issue as on the CI: no proper win-x86 output.

Using the -d flag for pkg I saw the following section:

> [debug] Targets:
  [
  {
    "nodeRange": "node6",
    "platform": "win",
    "arch": "x86",
    "output": "/root/vdds-client/client.exe",
    "forceBuild": false,
    "fabricator": {
      "nodeRange": "node6",
      "platform": "linux",
      "arch": "x86",
      "forceBuild": false,
      "binaryPath": "/root/.pkg-cache/v2.5/fetched-v6.11.5-linux-x86"
    },
    "binaryPath": "/root/.pkg-cache/v2.5/fetched-v6.11.5-win-x86"
  }
]

When trying to run the /root/.pkg-cache/v2.5/fetched-v6.11.5-linux-x86 it gave me the following error:

root@a2cd31593bb2:~/vdds-client# ls /root/.pkg-cache/v2.5/fetched-v6.11.5-linux-x86
/root/.pkg-cache/v2.5/fetched-v6.11.5-linux-x86
root@a2cd31593bb2:~/vdds-client# /root/.pkg-cache/v2.5/fetched-v6.11.5-linux-x86
bash: /root/.pkg-cache/v2.5/fetched-v6.11.5-linux-x86: No such file or directory

So I took a look:

root@a2cd31593bb2:~/vdds-client# file /root/.pkg-cache/v2.5/fetched-v6.11.5-linux-x86
/root/.pkg-cache/v2.5/fetched-v6.11.5-linux-x86: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=ac11506dd30ec242b56788701d1315efeed93910, not stripped

This triggered the idea that I did include the i386 support locally...

So I was able to fix it for my case (gitlab-ci, node:7 image) by installing glibc with i386 support by adding the following to the .gitlab-ci.yml script section:

    - dpkg --add-architecture i386
    - apt-get update
    - apt-get install -y libc6:i386 libstdc++6:i386

You might need to adapt for your setup;-) Installing ia32-libs instead of multiarch could be also a way, don't know about non-Debian systems...

[pionl]

@huerlisi suggestions works perfectly! I've create node image with i386 installed - https://github.com/pionl/docker-node-with-i386