Review state of canary in CI

[targos]

I finally found the time to update and fix canary, at least for my system (macOS, arm64)

Latest commit: 0a3560b
CI: https://ci.nodejs.org/job/node-test-commit/52045/

[targos]

node-test-commit-osx-arm is green 😇

[targos]

A lot of failures are:

12:11:31   ccache g++ -o /home/iojs/build/workspace/node-test-commit-linux/out/Release/obj.target/v8_libbase/deps/v8/src/base/platform/platform-posix-time.o ../deps/v8/src/base/platform/platform-posix-time.cc '-D_GLIBCXX_USE_CXX11_ABI=1' '-DNODE_OPENSSL_HAS_QUIC' '-DV8_GYP_BUILD' '-DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64' '-D__STDC_FORMAT_MACROS' '-DOPENSSL_NO_PINSHARED' '-DOPENSSL_THREADS' '-DV8_TARGET_ARCH_X64' '-DV8_HAVE_TARGET_OS' '-DV8_TARGET_OS_LINUX' '-DV8_EMBEDDER_STRING="-node.6"' '-DENABLE_DISASSEMBLER' '-DV8_PROMISE_INTERNAL_FIELD_COUNT=1' '-DOBJECT_PRINT' '-DV8_INTL_SUPPORT' '-DV8_ATOMIC_OBJECT_FIELD_WRITES' '-DV8_ENABLE_LAZY_SOURCE_POSITIONS' '-DV8_USE_SIPHASH' '-DV8_WIN64_UNWINDING_INFO' '-DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH' '-DV8_SNAPSHOT_COMPRESSION' '-DV8_ENABLE_WEBASSEMBLY' '-DV8_ENABLE_JAVASCRIPT_PROMISE_HOOKS' '-DV8_ALLOCATION_FOLDING' '-DV8_ALLOCATION_SITE_TRACKING' '-DV8_SCRIPTORMODULE_LEGACY_LIFETIME' '-DV8_ADVANCED_BIGINT_ALGORITHMS' '-DBUILDING_V8_BASE_SHARED' -I../deps/v8 -I../deps/v8/include  -pthread -Wno-unused-parameter -m64 -Wno-return-type -fno-strict-aliasing -m64 -O3 -fno-omit-frame-pointer -fdata-sections -ffunction-sections -O3 -fno-rtti -fno-exceptions -std=gnu++17 -MMD -MF /home/iojs/build/workspace/node-test-commit-linux/out/Release/.deps//home/iojs/build/workspace/node-test-commit-linux/out/Release/obj.target/v8_libbase/deps/v8/src/base/platform/platform-posix-time.o.d.raw   -c
12:11:32 ../deps/v8/src/base/platform/platform-posix.cc: In static member function ‘static v8::PlatformSharedMemoryHandle v8::base::OS::CreateSharedMemoryHandleForTesting(size_t)’:
12:11:33 ../deps/v8/src/base/platform/platform-posix.cc:581:31: error: ‘MFD_CLOEXEC’ was not declared in this scope
12:11:33    int fd = memfd_create(name, MFD_CLOEXEC);
12:11:33                                ^~~~~~~~~~~
12:11:33 ../deps/v8/src/base/platform/platform-posix.cc:581:12: error: ‘memfd_create’ was not declared in this scope
12:11:33    int fd = memfd_create(name, MFD_CLOEXEC);
12:11:33             ^~~~~~~~~~~~
12:11:33 ../deps/v8/src/base/platform/platform-posix.cc:581:12: note: suggested alternative: ‘timer_create’
12:11:33    int fd = memfd_create(name, MFD_CLOEXEC);
12:11:33             ^~~~~~~~~~~~
12:11:33             timer_create
12:11:33 make[2]: *** [tools/v8_gypfiles/v8_libbase.target.mk:179: /home/iojs/build/workspace/node-test-commit-linux/out/Release/obj.target/v8_libbase/deps/v8/src/base/platform/platform-posix.o] Error 1

Any idea?

[richardlau]

A missing include? I think the memory mapped stuff is in sys/mman.h on Linux.

[targos]

A missing include? I think the memory mapped stuff is in sys/mman.h on Linux.

Seems right: https://man7.org/linux/man-pages/man2/memfd_create.2.html

The problem is that the include is already there:

node-v8/deps/v8/src/base/platform/platform-posix.cc

Line 18 in 0a3560b

#include <sys/mman.h>

[richardlau]

A missing include? I think the memory mapped stuff is in sys/mman.h on Linux.

Seems right: https://man7.org/linux/man-pages/man2/memfd_create.2.html

The problem is that the include is already there:

node-v8/deps/v8/src/base/platform/platform-posix.cc

Line 18 in 0a3560b

#include <sys/mman.h>

The linked man page also has

 #define _GNU_SOURCE

before the include, which doesn't appear to be in either the deps/v8/src/base/platform/platform-posix.cc file or the failing command line.

[targos]

V8 added the call in v8/v8@7b2b3af
It doesn't seem like they needed to do anything to make it work.

[targos]

The weird thing is that most linux hosts compiled without errors: https://ci.nodejs.org/job/node-test-commit-linux/44849/

[richardlau]

It looks like most (all?) the failures of that type are centos 7/RHEL 7. I'm wondering if it's linked to the glibc version as there are other passing platforms using gcc 8.

FWIW I'm currently setting up RHEL 8 s390x machines and kicked off a canary build in the job I've been using to test them and it looks like the rhel8 machine is building this where the rhel7 one failed: https://ci.nodejs.org/job/richardlau-node-test-commit-linuxone/19/

[richardlau]

It looks like most (all?) the failures of that type are CentOS 7/RHEL 7. I'm wondering if it's linked to the glibc version...

From https://man7.org/linux/man-pages/man2/memfd_create.2.html#VERSIONS:

The memfd_create() system call first appeared in Linux 3.17;
glibc support was added in version 2.27.

CentOS 7/RHEL 7 is old (first released in 2014) and has glibc 2.17 [1]. The good news there is that we are planning to move building binaries for Node.js 18 onwards from CentOS 7 to RHEL 8 (nodejs/build#2815, nodejs/build#2741) so this may resolve itself over the next few weeks as I get RHEL 8 hosts added to the CI.

[1] Refs: https://distrowatch.com/dwres.php?resource=package-in-distro&pkg=glibc

[targos]

Does it mean we have to increase the minimum glibc for v18.0.0?

[targos]

@nodejs/v8 does Chromium document somewhere the minimum required versions of the Linux kernel and glibc?

[richardlau]

Does it mean we have to increase the minimum glibc for v18.0.0?

Yes, for the running the release binaries at least we'll need to raise the minimum glibc to 2.28 (as that is what is used by RHEL 8). It may be possible to still build against glibc versions earlier than that, but it looks like you'd need to be on at least 2.27 if the change on canary lands, according to the documentation.

[bnoordhuis]

Apropos that memfd_create error, that's in a function that's only used for testing. If you really wanted to keep compatibility with old kernels, you could float a patch that changes it to:

PlatformSharedMemoryHandle OS::CreateSharedMemoryHandleForTesting(size_t size) {
  return kInvalidSharedMemoryHandle;
}

[targos]

@bnoordhuis good point.

I added the following patch: nodejs/node@72f0932
Hope that makes sense.

[bnoordhuis]

@targos Compile-time feature checking means the binary won't run on older systems when it's compiled on a newer system. There are ways around that but I wouldn't bother in this particular case and just stub it out.

[targos]

nodejs/node@ec77f2d

[targos]

It looks like they didn't intend to bump glibc requirements: v8/v8@4e81f25
I removed my floating patch from canary.