I’m trying to use snapcraft remote-build on armhf with NodeJS LTS 10.4.1. NodeJS 10.4.1 supports ARMv6 and ARMv7 (the binaries are listed here: https://nodejs.org/en/download/) however pkg-fetch does not support ARMv6 and so it appears that remote-build is trying to compile NodeJS from source for ARMv6 as a fallback. Compiling from source stalls the build and renders remotebuild unable to build NodeJS parts. I left one instance running overnight and it eventually timed out.
Has anyone been able to build NodeJS on armhf with remote-build?
teg-host-posix: > pkg@4.3.7
teg-host-posix: > Fetching base Node.js binaries to PKG_CACHE_PATH
[06/Oct/2019:15:36:48 +0000] "CONNECT github.com:443 HTTP/1.1" 200 4961 "-" "zeit/pkg-fetch/undefined"
teg-host-posix:
teg-host-posix: > Error! 404 Not Found
teg-host-posix: https://github.com/zeit/pkg-fetch/releases/download/v2.5/uploaded-v2.5-node-v10.4.1-linux-armv6
teg-host-posix: > Asset not found by direct link:
teg-host-posix: {"tag":"v2.5","name":"uploaded-v2.5-node-v10.4.1-linux-armv6"}
[06/Oct/2019:15:36:49 +0000] "CONNECT api.github.com:443 HTTP/1.1" 200 99205 "-" "zeit/pkg-fetch/undefined"
teg-host-posix: > Not found in GitHub releases:
teg-host-posix: {"tag":"v2.5","name":"uploaded-v2.5-node-v10.4.1-linux-armv6"}
> Building base binary from source:
built-v10.4.1-linux-armv6
teg-host-posix: > Cloning Node.js repository from GitHub...
teg-host-posix:
teg-host-posix: > Checking out v10.4.1
[06/Oct/2019:15:38:17 +0000] "CONNECT github.com:443 HTTP/1.1" 200 519204135 "-" "git/2.17.1"
teg-host-posix: > Applying patches
teg-host-posix: > Compiling Node.js from sources...
I’m avoiding to use snapcraft remote-build by doing native build on my ARM based nvidia jetson devkit. Because nvidia didn’t enable the hypervisor, default multipass build fails and the solution was to build on the arm host instead:
SNAPCRAFT_BUILD_ENVIRONMENT=host snapcraft
Yes, it is relatively slow (more than hour) but that way I’m in full control of the build process and could quickly fix or at least investigate such issues.
This does not seem to be a remote-build specific problem, more so an issue with architectures. Our build servers have long ago dropped support for ARMv6, only v7 is supported (armhf) so pkg-fetch might be doing the wrong introspection, specifically, this piece of logic https://github.com/zeit/pkg-fetch/blob/f21733396c7452da465766144d514e4c91f7b6c5/lib/system.js#L63 … it should probably switch away from checking the CPU to checking the user space architecture.
The problem specific to remote-build here is that afaik all armhf remotebuilds run on ARMv6 remote-build servers. So, to be clear I would absolutely advocate for an ARMv7 remote-build option as it would solve this problem entirely.
The whole reason I am trying to use remote-build it to avoid the need for a raspberry Pi or alternatively the need to work out the rather involved process of cross compiling the binaries in my node modules (which as a Node dev that lacks experience in C++ my attempts at cross compilation have not gone well).
Remote-build is advertised as a cloud build service specifically for cross architecture builds. Since NodeJS can’t build any application - even a hello world - on one of remote-build’s architectures I believe that’s a failure to deliver on the promise of remote-build.
Again this could be solved by providing ARMv7 remote build targets.
Ubuntu’s armhf port has always been ARMv7, and hasn’t ever run on ARMv6, so that’s not possible.
snapcraft remote builds currently use the Launchpad build farm. At present, that means that armhf builds run on ARMv8 hardware, with ARMv8 kernels, but ARMv7 userspace. There’s no ARMv6 in play at all.
My apologies @wgrant, I’m happy to hear I’m incorrect on this one though. Glad to hear the servers are not ARMv6. But that leaves me not sure why the Node plugin is trying to download packages for ARMv6 by default on remote-build. The plugin is somehow defaulting to neither the kernel, hardware or userspace architecture which seems very strange to me? I would love if this could be resolved so that I can build NodeJS + ARMv7 on remote-build.
Sorry @sergiusens I see what your saying now. In addition to the issue of checking CPU instead of user space architecture you mention there is also the issue that (based on @wgrant’s comment) this is running on an ARMv8 CPU which it looks like there’s no check for here unless ARMv8 CPUs return a name that includes ‘ARMv7’?
Not sure how to go about getting this patched and applied to the remote-build services. How does this proceed?
Builds should never detect things based on the running kernel, or /proc/cpuinfo. They should base decisions on the system’s userspace architecture, so they work on a consistent set of hardware regardless of the hardware they’re built on.
However, since not all software obeys those sensible guidelines, our build systems’ ARMv8 kernels are configured to return armv7l as their architecture when running 32-bit code. So software that determines the architecture from uname should think it’s on an ARMv7 system.
