www/node2{2,4,6}: Use bundled merve to avoid loading two simdutfsHEADmain

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

0 files changed, 0 insertions, 0 deletions