On recent CURRENT (FreeBSD 16.0-CURRENT #6 master-n282239-57c0a337dbc5: Sat Nov 29 09:07:33 CET 2025 amd64), updating port www/node24 fails with error shown below: [...] c++ -o /usr/ports/www/node24/work/node-v24.11.1/out/Release/obj.target/v8_initializers/deps/v8/src/builtins/builtins-typed-array-gen.o ../deps/v8/src/builtins/builtins-typed-array-gen.cc '-D_GLIBCXX_USE_CXX11_ABI=1' '-D_FILE_OFFSET_BITS=64' '-DNODE_OPENSSL_CONF_NAME=nodejs_conf' '-DNODE_OPENSSL_CERT_STORE' '-DICU_NO_USER_DATA_OVERRIDE' '-DV8_GYP_BUILD' '-DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64' '-DBUILDING_V8_SHARED' '-D__STDC_FORMAT_MACROS' '-DV8_TARGET_ARCH_X64' '-DV8_EMBEDDER_STRING="-node.28"' '-DENABLE_DISASSEMBLER' '-DV8_PROMISE_INTERNAL_FIELD_COUNT=1' '-DV8_SHORT_BUILTIN_CALLS' '-DOBJECT_PRINT' '-DV8_INTL_SUPPORT' '-DV8_ATOMIC_OBJECT_FIELD_WRITES' '-DV8_ENABLE_LAZY_SOURCE_POSITIONS' '-DV8_USE_SIPHASH' '-DNDEBUG' '-DV8_WIN64_UNWINDING_INFO' '-DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH' '-DV8_USE_ZLIB' '-DV8_ENABLE_LEAPTIERING' '-DV8_ENABLE_SPARKPLUG' '-DV8_ENABLE_MAGLEV' '-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' '-DV8_ENABLE_WASM_SIMD256_REVEC' -I../deps/v8 -I../deps/v8/include -I/usr/ports/www/node24/work/node-v24.11.1/out/Release/obj/gen -I/usr/ports/www/node24/work/node-v24.11.1/out/Release/obj/gen/generate-bytecode-output-root -I../deps/v8/third_party/fp16/src/include -I../deps/v8/third_party/abseil-cpp -fvisibility=hidden -fvisibility-inlines-hidden -pthread -Wno-unused-parameter -m64 -O3 -fno-omit-frame-pointer -fdata-sections -ffunction-sections -O3 -fno-rtti -fno-exceptions -fno-strict-aliasing -std=gnu++20 -Wno-invalid-offsetof -Wno-nullability-completeness -MMD -MF /usr/ports/www/node24/work/node-v24.11.1/out/Release/.deps//usr/ports/www/node24/work/node-v24.11.1/out/Release/obj.target/v8_initializers/deps/v8/src/builtins/builtins-typed-array-gen.o.d.raw -isystem /usr/local/include -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -c ../deps/v8/src/builtins/builtins-sharedarraybuffer-gen.cc:156:52: error: too many arguments provided to function-like macro invocation 156 | Label done(this), range_error(this), unreachable(this); | ^ /usr/include/sys/cdefs.h:258:9: note: macro '__unreachable' defined here 258 | #define __unreachable() __builtin_unreachable() | ^ ../deps/v8/src/builtins/builtins-sharedarraybuffer-gen.cc:156:40: error: no matching constructor for initialization of 'Label' (aka 'v8::internal::compiler::CodeAssemblerLabel') 156 | Label done(this), range_error(this), unreachable(this); | ^ /usr/include/stddef.h:65:24: note: expanded from macro 'unreachable' 65 | #define unreachable(x) __unreachable(x) [...]
Hi, I've stumbled on this one too. It looks like this happens on very recent head only and is caused by a change to include/stddef.h which happened on November 27th [1] This does not mean that commit is wrong per se, but it looks like it causes issues in this ports with `__unreachable()` vs `__unreachable(x)`. I have no idea right away how to work around this at the ports level. I'll take the freedom to add the committer and his mentor to this report, maybe they can suggest a solution. [1] https://cgit.freebsd.org/src/commit/?id=b381d0980221b476cadbef862a8e5973d675fb7a
(In reply to Guido Falsi from comment #1) With some study I discover, v8, which is the failing part, is not C++23 compliant [1], and defines its own unreachable(). We expose our own though unless directed otherwise, so the failure. I'm trying to understand what is the correct way to not expose this define when compiling node, but all patches I've tested up until now have failed. [1] https://issues.chromium.org/issues/388070065
The easiest solution is to #undef our unreachable() macro when nodes' own is defined. unreachable() is part of C23 and will not go away.
(In reply to Robert Clausecker from comment #3) Thanks for the feedback. Please note I did not mean to comment negatively on your work. It simply triggers this issue, on a software doing something that it should not, I guess. I added you to CC hoping you could give some useful feedback, which you did, and I thank you for it. Unluckily a quick test adding `#undef unreachable` just before the definition in the v8 include file did not work. Maybe the files are included in a different order than expected, or there is something I am missing. My next idea is to define something like _POSIX_C_SOURCE with an appropriate value when compiling node24, but I'm fighting with the build system.
This bug and fix likely apply to node22 as well
Same problem with graphics/glslang: /wrkdirs/usr/ports/graphics/glslang/work/glslang-16.0.0/SPIRV/spvIR.h:639:78: error: too many arguments provided to function-like macro invocation 639 | __inline Block::Block(Id id, Function& parent) : parent(parent), unreachable(false) | ^ /usr/include/sys/cdefs.h:258:9: note: macro '__unreachable' defined here 258 | #define __unreachable() __builtin_unreachable()
(In reply to Nuno Teixeira from comment #6) (...) sysutils/nix too: ../src/libutil/include/nix/util/error.hh:313:45: error: variable has incomplete type 'void' 313 | [[gnu::noinline, gnu::cold, noreturn]] void unreachable(std::source_location loc = std::source_location::current()); | ^ /usr/include/stddef.h:65:24: note: expanded from macro 'unreachable' 65 | #define unreachable(x) __unreachable(x) Running on main-n282255-5bfdb66ad985: Sun Nov 30
Wouldn't it better reverting the offending commit and invoking full exp-run to give chance and time for affected ports to fix before reapplying? Possibly multiple exp-runs are needed, as there could be skipped but affected ports that depends on broken affected ports.
(In reply to Tomoaki AOKI from comment #8) See D54041 for an attempt to address this issue.
(In reply to Robert Clausecker from comment #9) Thanks! So we should wait for the reworked (again) patch to be landed, then, redo ports builds and see how it goes.
(In reply to Robert Clausecker from comment #9) Looking through the review D54041, do you think this the correct patch? diff --git a/include/stddef.h b/include/stddef.h --- a/include/stddef.h +++ b/include/stddef.h @@ -61,7 +61,7 @@ #endif #endif -#if __ISO_C_VISIBLE >= 2023 +#if __ISO_C_VISIBLE >= 2023 && !defined(unreachable) && !defined(__cplusplus) #define unreachable(x) __unreachable(x) #endif
(In reply to Tomoaki AOKI from comment #11) Yes, I think that patch would do the trick for C++ applications.
This has been reverted for now in base fc88be257e30c3e3c01f25ec3a3a6e7933b40c54. There has been some discussion in other places as more people have hit this and related errors in ports; there are issues beyond the leakage to C++. In C++, V8, as included in www/node25 at least, is a gnu++20 codebase (C++20 with GNU extensions) so there is no expectation that an unreachable() from C23 would be present; in fact V8 defines its own different unreachable(). It does, however, access __builtin_unreachable() that, with a tweak, eventually became C++23 unreachable(). Speaking of C++23 unreachable(), the visibility of C23 unreachable() in a C++23 context is still problematic, as seen with the www/webkit2-gtk errors. In a C context, there are some visibility conventions that need further working as new and updated standards in C, POSIX, etc proliferate. As of this writing, clang in base defaults to, and the appropriate -std passed for good measure in base system builds, C17. The preprocessor guard used (prior to revert) had unreachable() exposed effectively nearly unconditionally, causing valid codebases written for < C23 to error. More "common" words, like unreachable, used as variables may become reserved in future C standards, so a discussion is worth having, somewhere else, to at least reduce the impact on existing valid code written for older standards.
(In reply to Robert Clausecker from comment #12) Note for the future. Even with the patch on Comment #11, at least 2 ports below failed. Possibly stop limiting with !defined(__cplusppus) hepls. sysutils/bsdisks lang/guile3 Will try reverting the patch and upgrading to after commit base fc88be257e30c3e3c01f25ec3a3a6e7933b40c54 once ongoing ports builds are finished. And I'll report back if some more failure happen afterwards.
(In reply to Tomoaki AOKI from comment #14) Another record with the patch at comment 11. www/qt6-webengine. In file included from ../../../../../qtwebengine-everywhere-src-6.9.3/src/3rdparty/chromium/pdf/pdf_view_web_plugin.cc:5: In file included from ../../../../../qtwebengine-everywhere-src-6.9.3/src/3rdparty/chromium/pdf/pdf_view_web_plugin.h:32: In file included from ../../../../../qtwebengine-everywhere-src-6.9.3/src/3rdparty/chromium/pdf/pdfium/pdfium_engine_client.h:9: In file included from /usr/include/c++/v1/uchar.h:48: /usr/include/uchar.h:36:23: error: cannot combine with previous 'char' declaration specifier typedef unsigned char char8_t Not yet upgraded src, ports builds are still ongoing.
Here's another idea: We define unreachable as #define unreachable(...) unreachable(__VA_ARGS__) meaning, it is defined as itself. Then we define an inline function in <stddef.h> as follows: static inline void unreachable(void) { __unreachable(); } I'll have to check if that actually works, but if it does, it might just avoid these problems altogether.
(In reply to Tomoaki AOKI from comment #15) Backed out the patch at Comment #11, upgrade src to base f6aa57c86b6239e1f8c8ff50f28c9d0ed1af2ce3 but lang/guile3 and www/qt6-webengine still fail. In lang/guile3 case, it seems that failing in C code and the reason is functions without prototype cannot have argument in C23 (just deprecated on older specs), so adding CFLAGS+= -std=c11 in ports Makefile helped (tested with simple `make` only for now). For www/qt6-webengine case, Im interested in proposed fix on Comment #16. OTOH, sysutils/bsdisks went fine and now builds for its dependencies is on the way now.
(In reply to Tomoaki AOKI from comment #17) I don't really understand the qt6-webengine failure. char8_t is another new C23 type I added (see D53952 / base f0e541118c374869a8226eaa1320bb6eda248a20), but I don't see how the error message follows. This'll need additional investigation. Please do let me know if the approach from comment #16 works. I haven't tested it yet and am not quite sure if you can safely wrap __builtin_unreachable() into an inline function. If desired I can prepare a patch.
(In reply to Robert Clausecker from comment #18) If the patch below is what you mean, unfortunately it didn't help. Same failure with uchar. Completely different fix seem to be needed. (Here, to minimize turnaround time, applied to /usr/include/stddef.h alone.) Now, to be sure, rebuilding www/node24 again. --- a/include/stddef.h +++ b/include/stddef.h @@ -61,6 +61,17 @@ #endif #endif +#if __ISO_C_VISIBLE >= 2023 +#define unreachable(...) unreachable(__VA_ARGS__) +#if !defined(unreachable) +static inline void + unreachable(void) + { + __unreachable(); + } +#endif +#endif + #ifndef offsetof #define offsetof(type, field) __builtin_offsetof(type, field) #endif
(In reply to Tomoaki AOKI from comment #19) The uchar issue is likely unrelated and has to be investigated further.
(In reply to Robert Clausecker from comment #20) Yes. Should we neeed dedicated PR for it? Or continue here not to break discussion for future readers? Current test results with the patch at comment #19 are as below. Bare metal `make` for www/node24 finished fine. Bare metal `make` for lang/guile3 (with and without "CFLAGS+= -std=C11" hack) finished fine. And sysutils/bsdisk is untested, as it has different fix, commit ports 51cb57c4fee5d393d155be22b56eab07e20d1ce5 by cy@.
(In reply to Tomoaki AOKI from comment #21) Oh yes, that would be great. Please file a separate issue for the uchar case. The main issue with the patch from comment #19 is that I don't know if it still works as an unreachable() macro, so I'll have to do some testing before I can propose it. I'm happy that it seems to address the problem you are facing though.
(In reply to Robert Clausecker from comment #22) Filed Bug 291449 for www/qt6-webengine. Further discussion about www/qt6-webengine (and any others exhibiting the same failure mode) that aren't related with www/node24 should be done there.