nodejs: fix build on 32 bit platforms

[symphorien]

this test is failing on both armv7 and i686 and is related to year 2038 issue so it probably affects all 32 bit platforms

built rebased on another nixpkgs commit on armv7

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[Ma27]

and is related to year 2038 issue

I'm not sure if it's reasonable to ignore the test here, but I'll defer the decision to the maintainers.

[aduh95]

Could you share the output of the test failure? The test is supposed to skip if the platform doesn't have y2k38 support: https://github.com/nodejs/node/blob/428c3fd31b86706bb6987f7ae1b1ac398eb343cb/test/parallel/test-fs-utimes-y2K38.js#L19-L21 https://github.com/nodejs/node/blob/428c3fd31b86706bb6987f7ae1b1ac398eb343cb/test/parallel/test-fs-utimes-y2K38.js#L29-L31

A more interesting fix would be to fix those checks if they are insufficient or making wrong assumptions (I don't have a 32-bit platform to test that myself)

[JohnRTitor]

Just updated my flake inputs and found that node-js is building and failing in checkPhase (on x86_64 obviously) and an issue seperate from this.

┃        >   ...
┃        > ok 4059 known_issues/test-url-parse-conformance
┃        >   ---
┃        >   duration_ms: 56.50900
┃        >   ...
┃        > ok 4060 known_issues/test-vm-function-declaration-uses-define
┃        >   ---
┃        >   duration_ms: 36.65000
┃        >   ...
┃        > ok 4061 known_issues/test-vm-timeout-escape-nexttick
┃        >   ---
┃        >   duration_ms: 806.78800
┃        >   ...
┃        >
┃        > Failed tests:
┃        > out/Release/node /build/node-v23.2.0/test/parallel/test-os.js
┃        > make: *** [Makefile:558: test-ci-js] Error 1
┃        For full logs, run 'nix log /nix/store/ahgdyngidcphsmb7zn5b1lny589pyjdc-nodejs-23.2.0.drv'.

Isn't this supposed to be cached though? I am using zed from master/nixpkgs-unstable which is why it's pulling from master.

[Ma27]

and an issue seperate from this.

If this is an unrelated issue, why do you comment here instead of opening a new issue?

[JohnRTitor]

searched for any open PRs, and this is the first to pop up. But sure #355919

[symphorien]

I have gc-ed the toolchain since then so I cannot show you the exact failure but I can describe it: the test fails because the systemcall utimes fails with EINVAL. I confirmed with strace that utimensat is called with the nanosecond argument set to 100000000. The manpage documents that this argument is indeed invalid. I had a look in the source code and it is reasonably easy to understand.
This function converts the timestamp passed to utimensat from a double time (2**31 in the test) to struct timespec:

https://github.com/nodejs/node/blob/ecedcba357603a68530a0106d5bc0eb76bb89bcd/deps/uv/src/unix/fs.c#L206-L223

  ts.tv_sec  = time;
  ts.tv_nsec = (time - ts.tv_sec) * 1e9;

on 32 bit platform with 32 bit time_t, this results in an invalid computation where tv_sec is INT_MAX and tv_nsec contains a full second instead of a fractional part of a second.

The only solution for this test to pass, is to compile every package with -D_TIME_BITS=64. Source:
https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration

Libraries using time_t directly or indirectly needs to be switched at the same time. Applications using any such libraries must be switched at the same time too.

Additionally, doing this might not be a good idea on i386 because it is likely that the most frequent usage of i386 libraries is to make old, binary only software work on x86_64 and compiling with -D_TIME_BITS=64 breaks ABI. See https://lwn.net/Articles/938149/

As a result my impression is that:

• this change is admittedly a bandaid which hides that node will break in 2038
• the good solution is to change stdenv to compile with -D_TIME_BITS=64 . This has deep consequences, and deserves discussion about i386.
  I would like to not block on such a better solution.

[symphorien]

Hi, can we move this forward?