www/node2{2,4}: fix safepoints after calls on powerpc64*
Backport V8 f331137d5968 and 3d0a73103b97. The assembler can put its
trampoline pool right after a call, and the safepoint and exception
handler for that call are then recorded at the wrong address, so the
GC can scan the wrong stack slots and exceptions can skip their catch
block.
www/node24: drop -mpower8-vector
simdutf enables its POWER code whenever AltiVec is available, but that
code needs POWER8. Backport simdutf 573d42d7, which also checks for
POWER8, and drop the flag. There are no official powerpc64 packages,
so anyone who wants the POWER8 code can set CPUTYPE.
www/node2{2,4,6}: detect the CPU on powerpc64*
V8 only detects the CPU on Linux and AIX. On FreeBSD it assumes the
oldest CPU it supports, so node 22 and 24 never use POWER9 code and
reject every Wasm module that uses SIMD. Read the ISA level from
AT_HWCAP and AT_HWCAP2 instead.
www/node2{2,4,6}: Use bundled merve to avoid loading two simdutfs
node dies with SIGBUS (signal 10) the first time it lexes the exports
of a CommonJS module, e.g. early in any `npm install`, for example
www/tailwindcss4 fails to build, reporting "*** Signal 10".
Running lldb inside poudriere build, because we get a core dump:
frame #0 libsimdutf.so.36 simdutf::detail::find(...) +77: jmpq *%rax
frame #1 libmerve.so.1 lexer::CJSLexer::addReexport(...)
...
frame #6 node node::cjs_lexer::Parse(...)
rax = 0x4444444443434343 ("CCCCDDDD", string data)
This appears to be caused by having two different simdutf versions
loaded into one process:
- node is configured with --shared-merve but not --shared-simdutf, so
it statically includes its own simdutf (7.7.0 in 26.10.0, from
deps/v8/third_party/simdutf), and exports those symbols for native
addons (`nm -D node | grep -c simdutf` = 686).
- devel/merve is built with MERVE_USE_SIMDUTF=ON and links the system
libsimdutf.so.36 from converters/simdutf (9.2.1).
Both define simdutf::get_active_implementation() and friends. rtld
searches the executable first, so references made from inside
libsimdutf.so.36 can bind to node's 7.7.0 copy. The 9.2.1 code then
reads a 7.7.0 implementation object with its own layout, loads string
data where it expects a function pointer, and jumps to it.
I tried dropping shared-merve from the port and corresponding
LIB_DEPENDS, and now things work again.
Alternatively both --shared-merve and --shared-simdutf could be used,
but this may result in behavioural changes for consumers. This should
probably be done in the next minor nodejs version bump.
Approved by: portmgr (fix blanket)
MFH: 2026Q4
PR: 299170
Reported by: poudriere
Sponsored by: SkunkWerks, GmbH
www/node24: Update to 24.14.0
- Use the following ports instead of the bundled ones
- devel/googletest
- devel/merve
- graphics/hdr_histogram
- www/nbytes
Changes: https://github.com/nodejs/node/releases
https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V24.md
www/node24: Update to 24.13.1
- Use the following ports instead of the bundled ones
- devel/libada
- devel/uvwasi
Changes: https://github.com/nodejs/node/releases
https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V24.md
Security: CVE-2026-21637
www/node2{0,2,4,5}: Don't depend on security/ca_root_nss anymore
When node.js is being build with an external OpenSSL (shared linking) the option
'--openssl-use-def-ca-store' ensures that OpenSSL uses the system truststore
managed by certctl(8). If the bundled OpenSSL is used node.js comes also bundled
with a Mozilla CA bundle as well. In any case security/ca_root_nss is not required.
PR: 291482
Approved by: sunpoet (maintainer)
www/node24: Use bundled sqlite3
- Bump PORTREVISION for dependency and package change
nodejs 22+ needs sqlite3 with SESSION enabled.
PR: 290509
Reported by: dim