FTBFS, version 22.11, gcc 11.2

[moonlitbugs]

On a Slackware64-15.0 machine, attempting to compile NodeJS 22.11 gets a ways into the compile and then fails. Compiling previous stable releases, e.g. 20.18 and below, works just fine.

On Slackware 15 (the most recent "stable" release, albeit dated), we have gcc version 11.2.0, and glibc version 2.33.

(On a Slackware64-current machine, with gcc version 14.2.0 and glibc version 2.40, the compile of NodeJS 22.11 works just fine. Alas, we can't use the binary compiled here on the older system due to missing glibc symbols.)

I am not a c++/g++ expert, and am unsure how to interpret these specific compiler errors:

../deps/v8/src/compiler/wasm-compiler.cc: In lambda function:
../deps/v8/src/compiler/wasm-compiler.cc:8620:59: error: too many initializers for ‘v8::internal::wasm::WrapperCompilationInfo::<unnamed union>’
 8620 |             .import_info = {kind, expected_arity, suspend}},
      |                                                           ^
../deps/v8/src/compiler/wasm-compiler.cc: In function ‘v8::internal::wasm::WasmCompilationResult v8::internal::compiler::CompileWasmImportCallWrapper(v8::internal::wasm::CompilationEnv*, v8::internal::wasm::ImportCallKind, const FunctionSig*, bool, int, v8::internal::wasm::Suspend)’:
../deps/v8/src/compiler/wasm-compiler.cc:8658:76: error: use of ‘v8::internal::compiler::CompileWasmImportCallWrapper(v8::internal::wasm::CompilationEnv*, v8::internal::wasm::ImportCallKind, const FunctionSig*, bool, int, v8::internal::wasm::Suspend)::<lambda()>’ before deduction of ‘auto’
 8658 |   auto result = v8_flags.turboshaft_wasm_wrappers ? compile_with_turboshaft()
      |                                                     ~~~~~~~~~~~~~~~~~~~~~~~^~
../deps/v8/src/compiler/wasm-compiler.cc: In lambda function:
../deps/v8/src/compiler/wasm-compiler.cc:8782:63: error: too many initializers for ‘v8::internal::wasm::WrapperCompilationInfo::<unnamed union>’
 8782 |                 .import_info = {kind, expected_arity, suspend}},
      |                                                               ^
  g++ -o /usr/local/tmp/slackbuild/nodejs/node-v22.11.0/out/Release/obj.target/v8_base_without_compiler/deps/v8/src/baseline/baseline.o ../deps/v8/src/baseline/baseline.cc '-D_GLIBCXX_USE_CXX11_ABI=1' '-DNODE_OPENSSL_CONF_NAME=nodejs_conf' '-DICU_NO_USER_DATA_OVERRIDE' '-DV8_GYP_BUILD' '-DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64' '-D__STDC_FORMAT_MACROS' '-DV8_TARGET_ARCH_X64' '-DV8_HAVE_TARGET_OS' '-DV8_TARGET_OS_LINUX' '-DV8_EMBEDDER_STRING="-node.21"' '-DENABLE_DISASSEMBLER' '-DV8_PROMISE_INTERNAL_FIELD_COUNT=1' '-DV8_ENABLE_PRIVATE_MAPPING_FORK_OPTIMIZATION' '-DV8_SHORT_BUILTIN_CALLS' '-DOBJECT_PRINT' '-DV8_INTL_SUPPORT' '-DV8_ATOMIC_OBJECT_FIELD_WRITES' '-DV8_ENABLE_LAZY_SOURCE_POSITIONS' '-DV8_USE_SIPHASH' '-DV8_SHARED_RO_HEAP' '-DNDEBUG' '-DV8_WIN64_UNWINDING_INFO' '-DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH' '-DV8_USE_ZLIB' '-DV8_ENABLE_SPARKPLUG' '-DV8_ENABLE_TURBOFAN' '-DV8_ENABLE_WEBASSEMBLY' '-DV8_ENABLE_JAVASCRIPT_PROMISE_HOOKS' '-DV8_ENABLE_CONTINUATION_PRESERVED_EMBEDDER_DATA' '-DV8_ALLOCATION_FOLDING' '-DV8_ALLOCATION_SITE_TRACKING' '-DV8_ADVANCED_BIGINT_ALGORITHMS' '-DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC' '-DUCONFIG_NO_SERVICE=1' '-DU_ENABLE_DYLOAD=0' '-DU_STATIC_IMPLEMENTATION=1' '-DU_HAVE_STD_STRING=1' '-DUCONFIG_NO_BREAK_ITERATION=0' -I../deps/v8 -I../deps/v8/include -I/usr/local/tmp/slackbuild/nodejs/node-v22.11.0/out/Release/obj/gen/inspector-generated-output-root -I../deps/v8/third_party/inspector_protocol -I/usr/local/tmp/slackbuild/nodejs/node-v22.11.0/out/Release/obj/gen -I/usr/local/tmp/slackbuild/nodejs/node-v22.11.0/out/Release/obj/gen/generate-bytecode-output-root -I../deps/icu-small/source/i18n -I../deps/icu-small/source/common -I../deps/v8/third_party/zlib -I../deps/v8/third_party/zlib/google -I../deps/v8/third_party/abseil-cpp -I../deps/v8/third_party/fp16/src/include  -pthread -Wno-unused-parameter -Wno-strict-overflow -Wno-return-type -Wno-int-in-bool-context -Wno-deprecated -Wno-stringop-overflow -Wno-stringop-overread -Wno-restrict -Wno-array-bounds -Wno-nonnull -Wno-dangling-pointer -flax-vector-conversions -m64 -m64 -O3 -fno-omit-frame-pointer -fdata-sections -ffunction-sections -O3 -fno-rtti -fno-exceptions -fno-strict-aliasing -std=gnu++20 -Wno-invalid-offsetof -MMD -MF /usr/local/tmp/slackbuild/nodejs/node-v22.11.0/out/Release/.deps//usr/local/tmp/slackbuild/nodejs/node-v22.11.0/out/Release/obj.target/v8_base_without_compiler/deps/v8/src/baseline/baseline.o.d.raw  -g -O2 -fPIC -march=opteron -c

[richardlau]

Not really sure this helps, but we do compile Node.js 22.x against a variety of Linux distros (Slackware isn't one of them), with differing compiler versions, all the way down to gcc 10.

On Slackware 15 (the most recent "stable" release, albeit dated), we have gcc version 11.2.0, and glibc version 2.33.

The nearest we have to that is Ubuntu 22.04 which is gcc 11.4.0 and glibc 2.35. For reference, the CI run on that platform for Node.js 22.11.0: https://ci.nodejs.org/job/node-test-commit-linux/61346/nodes=ubuntu2204-64/consoleFull

[moonlitbugs]

I'm going to try a trick I use to compile nghttp2, which requires std c++20. I built a gcc-14 compiler on the older system, remove libstdc++.so to force linking statically to libstdc++.a, build the package, and then restore the toolchain back to its vendor state.

If this succeeds with NodeJS 22.11, then I guess we can chock it up to a compiler error; this is assuming that the CI environment succeeds with gcc 11.4. It's an old Athlon-II machine, will take awhile...

[moonlitbugs]

Compile finished, new nodejs-22.11.0 package installed, seems to work fine. As per my previous comment, this is using a hand-compiled gcc-14.1 replacing the vendor gcc-11.2 on the old, stable distribution; no other libraries or dependencies were changed.

So, it would appear that this bug is something specific to gcc-11 and possibly more narrowly to gcc-11.2. As far as I know, the only file it cannot compile is deps/v8/src/compiler/wasm-compiler.cc (which is encountered about an hour into the 3-hour compile on this old CPU). Is there a small syntactic fix that would make it work, especially considering that everything else does so?

I have no feel for how many stable Linux distros are out there that also use gcc-11.2. If it's small, perhaps we should just close this? Wait for a few days to see if there are any other "me too"s?

I reported a similar issue affecting nghttp2 here, the aftermath of which saw a flurry of commits to other packages (e.g. curl, Homebrew/brew, nodejs/build) blocking the update to the regressed version. In other words, this FTBFS might be a blocker to some other projects.

[bnoordhuis]

Is there a small syntactic fix that would make it work, especially considering that everything else does so?

Writing it out in full probably fixes it:

wasm::WrapperCompilationInfo ci;
ci.code_kind = CodeKind::WASM_TO_JS_FUNCTION;
ci.import_info.import_kind = import_kind;
ci.import_info.expected_arity = expected_arity;
ci.import_info.suspend = suspend;

[moonlitbugs]

Thank you, @bnoordhuis - your hunch was correct. I applied your fix to the two places it occurs (fixing the import_kind = import_kind typo), and it now compiles without error.

FWIW, here is the simple patch I made and applied:

diff --git a/deps/v8/src/compiler/wasm-compiler.cc b/deps/v8/src/compiler/wasm-compiler.cc
--- a/deps/v8/src/compiler/wasm-compiler.cc     2024-10-28 21:25:11.000000000 -0400
+++ b/deps/v8/src/compiler/wasm-compiler.cc     2024-11-01 02:02:22.554537121 -0400
@@ -8613,11 +8613,13 @@
                  '-');
 
   auto compile_with_turboshaft = [&]() {
+    wasm::WrapperCompilationInfo ci;
+    ci.code_kind = CodeKind::WASM_TO_JS_FUNCTION;
+    ci.import_info.import_kind = kind;
+    ci.import_info.expected_arity = expected_arity;
+    ci.import_info.suspend = suspend;
     return Pipeline::GenerateCodeForWasmNativeStubFromTurboshaft(
-        env->module, sig,
-        wasm::WrapperCompilationInfo{
-            .code_kind = CodeKind::WASM_TO_JS_FUNCTION,
-            .import_info = {kind, expected_arity, suspend}},
+        env->module, sig, ci,
         func_name, WasmStubAssemblerOptions(), nullptr);
   };
   auto compile_with_turbofan = [&]() {
@@ -8774,12 +8776,14 @@
       base::VectorOf(name_buffer.get(), kMaxNameLen) + kNamePrefixLen, sig);
 
   auto compile_with_turboshaft = [&]() {
+    wasm::WrapperCompilationInfo ci;
+    ci.code_kind = CodeKind::WASM_TO_JS_FUNCTION;
+    ci.import_info.import_kind = kind;
+    ci.import_info.expected_arity = expected_arity;
+    ci.import_info.suspend = suspend;
     std::unique_ptr<turboshaft::TurboshaftCompilationJob> job =
         Pipeline::NewWasmTurboshaftWrapperCompilationJob(
-            isolate, sig,
-            wasm::WrapperCompilationInfo{
-                .code_kind = CodeKind::WASM_TO_JS_FUNCTION,
-                .import_info = {kind, expected_arity, suspend}},
+            isolate, sig, ci,
             nullptr, std::move(name_buffer), WasmAssemblerOptions());
 
     // Compile the wrapper

As CI works just fine with gcc 11.4, I guess we can close this off as being nothing more than a gcc 11.2 bug. Feel free to apply the simple patch above if it might help anybody; I am sure a modern compiler would optimize it away.

Not sure proper etiquette here for issue closing; I'll let one of the maintainers close this if/when it doesn't need any further attention.

[bnoordhuis]

I think we'd be okay with floating a small patch like that if you want to open a pull request. We normally have an "upstream first" policy but IMO it's reasonable to make an exception here because it's for a compiler upstream doesn't support.

[toddr]

FYI, Node 22.11.0 isn't building on Almalinux 8 either. I'm building with:

/usr/bin/scl enable gcc-toolset-11 -- ./configure --prefix=/usr/local/cpanel/3rdparty/node/22 --verbose --with-intl=small-icu --without-corepack
scl enable gcc-toolset-11 -- make

[i3v]

I'd like to report that the patch worked for me (CentOS7, devtoolset11).
I also had to apply this patch.

BTW, the BUILDING.md (current main) already requires gcc >= 12.2 ...