nvm install falls back immediately to source tarfile if binary tarfile fails for whatever reason

[theofficialgman]

trafficstars

installing with nvm install --lts on Bullseye ARM64 produces unexpected code compilation after the tarfile is downloaded

Computing checksum with sha256sum
Checksums matched!
$>./configure --prefix=/home/runner/.nvm/versions/node/v20.18.0 <
Node.js configure: Found Python 3.9.2...
INFO: configure completed successfully
/usr/bin/make -C out BUILDTYPE=Release V=0
  g++ -o /home/runner/.nvm/.cache/src/node-v20.18.0/files/out/Release/obj.target/simdutf/deps/simdutf/simdutf.o ../deps/simdutf/simdutf.cpp '-D_GLIBCXX_USE_CXX11_ABI=1' '-DNODE_OPENSSL_CONF_NAME=nodejs_conf' '-DNODE_OPENSSL_HAS_QUIC' '-DICU_NO_USER_DATA_OVERRIDE' '-D__STDC_FORMAT_MACROS' '-DOPENSSL_NO_PINSHARED' '-DOPENSSL_THREADS' -I../deps/simdutf  -pthread -Wall -Wextra -Wno-unused-parameter -O3 -fno-omit-frame-pointer -fno-rtti -fno-exceptions -std=gnu++17 -MMD -MF /home/runner/.nvm/.cache/src/node-v20.18.0/files/out/Release/.deps//home/runner/.nvm/.cache/src/node-v20.18.0/files/out/Release/obj.target/simdutf/deps/simdutf/simdutf.o.d.raw   -c

...

The compilation continues for hours (on a slow machine).

This issue does not occur on Bullseye ARMhf, Bookworm ARMhf, or Bookworm ARM64. There is no code compilation for those systems.

[ljharb]

I'm not sure why this is unexpected - node only provides builtin binaries for a finite number of systems, and anything beyond this must be compiled.

Please fill out the entirety of the issue template, every time - it's there for a reason.

[theofficialgman]

Please fill out the entirety of the issue template, every time - it's there for a reason.

@ljharb I would gladly but there are no issues templates on this repository

[ljharb]

Weird, https://github.com/nvm-sh/nvm/blob/master/.github/ISSUE_TEMPLATE.md Must have suddenly stopped working. I’ll fix that.

[ljharb]

Either way, do you expect node to provide a binary for that system?

[theofficialgman]

Either way, do you expect node to provide a binary for that system?

Yes, because now (that the same command results in 22) it does provide a binary. When --lts first pointed to 20 it also provided a binary. Hence the inconsistency.

[ljharb]

ok, so given that nvm doesn’t do anything different between 20 and 22, that suggests that either node simply didn’t provide a binary for that version, or that something transient on your machine caused it.

If you nvm install 20.18.0 now, do you get a binary?

[theofficialgman]

ok, so given that nvm doesn’t do anything different between 20 and 22, that suggests that either node simply didn’t provide a binary for that version, or that something transient on your machine caused it.

If you nvm install 20.18.0 now, do you get a binary?

I discovered the issue. nvm falls back to downloading the source only tarfile file if the binary tarfile fails for any reason. The binary tarfile download failed (see CI https://github.com/Botspot/pi-apps/actions/runs/11573517499/job/32215859679#step:7:4001) midway likely due to a nodejs server error (probably got overloaded and killed the connection). This is a bad way to do things and it should first attempt to download the file again (continuing off from where it left off) a few times before aborting and downloading the source tarfile. I'll rename the issue appropriately.