nvm
nvm copied to clipboard
Add the ability to use nvm with 32bit releases as well as 64bit
It would be really useful if we could use nvm to install 32bit versions of node so that we could make testing quicker.
Perhaps we could pass in a flag to the end like nvm install 6 -a x86
or something like that?
Any arguments passed after nvm install -s 6
will be passed through to the configure/make/make install - what command would you use to build a 32 bit version from source?
I'm curious, what's your use case that needs testing of 32 bit versions of node?
@ljharb Tends to be supporting people who are still using 32 bit (and debugging 32 bit specific issues).
The command would be ./configure --dest-cpu=$ARCH
where $ARCH
is one of https://github.com/nodejs/node/blob/master/configure#L36-L37. You could also pass DESTCPU=$ARCH
to the make command.
So one of: arm
, ppc
, x86
, s390
@ljharb But wouldn't that mean building from source? The tarballs should be available on nodejs.org, so would it be possible to just specify the arch there?
so exporting DESTCPU=$ARCH
does work but it seems slightly unnecessary to be building from source when the community already publish 32 bit tarballs
If a binary exists, and you're on that architecture, nvm
should certainly install it.
However, I'm not sure I see the value in overriding the arch - you're not actually truly testing a 32 bit node unless you're on a 32 bit machine. Isn't that what Docker is for?
@ljharb AFAIK running 32 bit binaries on 64 bit machines is something that people do, for lower memory footprint etc. I think we actually run some tests for some of the 32 bit node binaries on 64 bit machines in Node core (could well be wrong though). I'd certainly say that there's value in having the ability to use a 32-bit binary.
I guess you wouldn't need to specify the arch, just have a "use 32-bit equivalent" flag.
I'm not yet convinced this should be added, but I'd be happy to review a PR that added that flag.
(To reiterate: if we're not selecting the proper 32-bit binary on any 32-bit systems where it's available, that's a bug, and I'd love a separate issue or PR to fix that)
A very valid use case: building an Electron app on macOS that needs to target 32-bit Windows (i.e. Windows 7). See https://github.com/addaleax/lzma-native/issues/22#issuecomment-229769202 for an example. I'm trying to implement those steps and wish nvm could install the 32-bit version of v8.10.0 on my Mac.
I'm not a Windows or nvm expert, but FWIW it looks like the nvm-windows project has implemented this: https://github.com/coreybutler/nvm-windows/issues/134#issuecomment-231321138
If a binary exists, and you're on that architecture, nvm should certainly install it.
After looking at this further, I'm not even sure installing x86 Node on a Mac is even possible without a ton of wrangling from original source because they don't even release an x86 build of Node for Mac: https://nodejs.org/dist/latest-v8.x/ I guess I will need to try developing on Windows command line 😭
I definitely think that if you’re targeting X, you need to be developing and/or testing on X natively.
I have a use case:
- I prefer to develop in 64 bit for most of my applications
- Although I need to make a nodejs c++ addon that features a dll library (problem: dll is 32 bit only)
@keleko34 this the exactly same place i'm right now, trying to add a lib with ffi but the .so is compiled with 32 bits so i can't bind...
You can nvm install node x32 with "nvm install version_node 32"
@son0212 that is not a thing and never has been. You're thinking of nvm-windows
, which is an entirely different project.
So I had to essentially do this process manually this week because I'm working with a swc plugin that essentially compiles down to a wasm32-wasi target which then becomes impossible to load in an arm64 node build on an M1 mac
Essentially what I ended up doing was using nvm to install Node 16 (which is the same as my system version) and then replaced the contents of the folder with the nodejs.org deployed binaries for 32bit (because if you use the installer it will automatically install the arm64) binary.
There is no way around this until rust better supports the [wasm64-unknown-unknown](https://doc.rust-lang.org/nightly/rustc/platform-support/wasm64-unknown-unknown.html) target
which is currently a Tier 3 target which means:
Tier 3 targets are those which the Rust codebase has support for, but which the Rust project does not build or test automatically, so they may or may not work. Official builds are not available.
and even if Rust does properly support wasm64-unknown-unknown
eventually there are some SWC plugins that require wasi support so that means there is currently no support for any target that works on an M1 mac i.e. wasm64-wasi
just doesn't exist, supported or not 🙈