Cannot start Packem on MacOS (10.14.4)
Closed this issue ยท 10 comments
OS: 10.14.4
Node: Tried 10.4.1 & 11.14.0
I followed installation instructions, but get following error:
Initializing bundle process...internal/modules/cjs/loader.js:731
return process.dlopen(module, path.toNamespacedPath(filename));
^
Error: dlopen(/Users/dveremchuk/.nodebrew/node/v10.4.1/lib/node_modules/packem/bin/index.node, 1): no suitable image found. Did find:
/Users/dveremchuk/.nodebrew/node/v10.4.1/lib/node_modules/packem/bin/index.node: unknown file type, first eight bytes: 0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x00
/Users/dveremchuk/.nodebrew/node/v10.4.1/lib/node_modules/packem/bin/index.node: unknown file type, first eight bytes: 0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x00
at Object.Module._extensions..node (internal/modules/cjs/loader.js:731:18)
at Module.load (internal/modules/cjs/loader.js:612:32)
at tryModuleLoad (internal/modules/cjs/loader.js:551:12)
at Function.Module._load (internal/modules/cjs/loader.js:543:3)
at Module.require (internal/modules/cjs/loader.js:650:17)
at require (internal/modules/cjs/helpers.js:20:18)
at Object.<anonymous> (/Users/dveremchuk/.nodebrew/node/v10.4.1/lib/node_modules/packem/src/core.js:22:33)
at Module._compile (internal/modules/cjs/loader.js:702:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:713:10)
at Module.load (internal/modules/cjs/loader.js:612:32)
Try uninstalling packem
npm uninstall packem --save
Then reinstall it globally
npm install -g packem
If the issue still persists, then try
npm rebuild packem
Let me know how it goes.
There's no use to try npm uninstall packem --save && npm install -g packem && npm rebuild packem. The cause is very simple.
The index.node file is an 64-bit ELF binary. There is no way it can be run on the macOS.
$ file index.node
index.node: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=ff58937c5b0435fef8a9237d3c54350e7d8ec127, with debug_info, not strippedIn addition, there is no guarantee that it will run on Linux. The index.node file is a dynamically linked binary, and will not run unless the shared objects' version is correct.
$ ldd index.node
linux-vdso.so.1 (0x00007ffd693e6000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f4a723e5000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007f4a723db000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f4a723ba000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f4a723a0000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f4a721dc000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007f4a729a6000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f4a72057000)By the way, I think it would be a good idea to strip(1) the binary because the binary is too bloated with a lot of debug information. And I hope the Rust codes used to make the binary will be open source together someday. (See also: #4)
@simnalamburt Of course it wouldn't work if Packem functioned the way you presumed. However, your surface-level assumption is incorrect. Had you understood Packem's internals, you'd not make such a silly mistake. Reinstalling Packem triggers its build script which downloads and installs the appropriate pre-built Packem binaries for the underlying system.
Of course, index.node present in the repo will not work on macOS, this binary reflects Packem lastest build from the last OS (which was linux in this case) and it is not even included in Packem's npm package, meaning it does not even make it to the end-user's computer. Then again, had you inquired about this, I bet you'd not present ill-informed answers.
As for stripping the binaries of debug info, I'll remind you that this is an alpha pre-release version, in other words, this is intended. I'm certain we've clearly highlighted that Packem's not production ready in our README.md. Again, had you sought more on this topic, you'd not... (you know how it goes).
It is these sort of misleading answers that breed unnecessary confusion that could've otherwise be averted. Kindly do refrain from this.
Had you understood Packem's internals, you'd not make such a silly mistake.
I'm afraid I'm not the one who made a mistake.
As you mentioned, the latest Node.js users download and unzip https://github.com/packem/packem/releases/download/0.1.3/node-v67-darwin-x64.tar.gz, extract the index.node file from the tarball and install it. That index.node file is the one which is same with eaf80d3.
And I'm afraid that index.node binary is ELF, which is no way it can be run on the macOS.
I'm sorry. But I don't appreciate your tone. Thanks.
This is a macOS CI build related bug. It's being addressed.
In addition, there is no guarantee that it will run on Linux.
BTW, I've tested the linux myself before (Ubuntu 18, 16, 14), it's all good.
I'm sorry. But I don't appreciate your tone. Thanks.
I'm sorry you feel that way. My point is you're not (atleast yet) capable of pinpointing the exact issue. But thanks for the input, it was useful.
Yes I'm not able to pinpoint the exact issue, because the Rust codes and the CI scripts are not open sourced. From the user's point of view, there is nothing users can say except that the index.node file is not ELF. This is the best users can do unless they hack your computers.
And about dynamically linked binaries, I'll show you the exact examples.
CentOS 7.6, RHEL 7.6, and Fedora users are not able to use packem because version of the glibc shared object does not match.
$ cat /etc/centos-release
CentOS Linux release 7.6.1810 (Core)
$ packem
โ Initializing bundle process...internal/modules/cjs/loader.js:857
return process.dlopen(module, path.toNamespacedPath(filename));
^
Error: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /usr/local/share/.config/yarn/global/node_modules/packem/bin/index.node)
at Object.Module._extensions..node (internal/modules/cjs/loader.js:857:18)
at Module.load (internal/modules/cjs/loader.js:685:32)
at Function.Module._load (internal/modules/cjs/loader.js:620:12)
at Module.require (internal/modules/cjs/loader.js:723:19)
at require (internal/modules/cjs/helpers.js:14:16)
at Object.<anonymous> (/usr/local/share/.config/yarn/global/node_modules/packem/src/core.js:22:33)
at Module._compile (internal/modules/cjs/loader.js:816:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:827:10)
at Module.load (internal/modules/cjs/loader.js:685:32)
at Function.Module._load (internal/modules/cjs/loader.js:620:12)Alpine Linux users are not able to use packem because shared object loader (ld-linux) does not present. Alpine Linux is a popular distribution on the Docker.
$ cat /etc/alpine-release
3.9.3
$ packem
โ Initializing bundle process...internal/modules/cjs/loader.js:857
return process.dlopen(module, path.toNamespacedPath(filename));
^
Error: Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /root/node_modules/packem/bin/index.node)
at Object.Module._extensions..node (internal/modules/cjs/loader.js:857:18)
at Module.load (internal/modules/cjs/loader.js:685:32)
at Function.Module._load (internal/modules/cjs/loader.js:620:12)
at Module.require (internal/modules/cjs/loader.js:723:19)
at require (internal/modules/cjs/helpers.js:14:16)
at Object.<anonymous> (/root/node_modules/packem/src/core.js:22:33)
at Module._compile (internal/modules/cjs/loader.js:816:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:827:10)
at Module.load (internal/modules/cjs/loader.js:685:32)
at Function.Module._load (internal/modules/cjs/loader.js:620:12)The easiest way to solve this problem is to provide a fully statically-built binary that does not even depend on glibc. You can achieve this by using musl libc. Many programs developed with native codes, such as ripgrep and node-sass, solve this problem with static building using musl libc. If you open source the Rust codes, I will help you with that process.
Related with #4
I'm aware of this. Thanks for stating the obvious. However, at this moment, we do not intend to support any linux distros beside Ubuntu. I'm busy with the Windows builds and implementing other features of greater concern and more pressing needs.
Thanks everyone. I don't see this discussion heading anywhere. I'll be locking it for now until the issue is resolved. If you have any further suggestions, join our Gitter channel.
The internal CI server error has been resolved. macOS prebuilt libs are in order. The latest patch (packem@0.1.4) comes with better build improvements.