Nothing really unexpected. On the plus side, the jdks built and I saw no ocaml-related failures like we saw on aarch64. I haven't done any Java runtime testing yet - unsure how much that is exercised during bulks.
The biggest issue I found are boringssl's perlasm generated .S files that are at least in qtwebengine, the chrome derivatives and in whatever uses a copy of the ring crate. Those will usually result in a runtime failure. Most of them should be findable by grepping for '*-x86_64.S' and '*-x86_64.pl' over full build logs (like everything OpenSSL-related consistency is absent). Below is the full list of failed ports (minus mkhuman and warzone2100) with some comments. gcc variants: devel/ti-msp430gcc devel/xtensa-elf/gcc devel/xtensa-esp32-elf/newlib devel/xtensa-esp32s2-elf/newlib devel/xtensa-esp32s3-elf/newlib devel/xtensa-lx106-elf/newlib phessler treated most (all?) of these with the USE_NOEXECONLY hammer. Likely properly fixable once we figure out a fix for lang/gcc/*. lang/ghc ghc-cabal segfaults during build. gnezdo is looking. lang/node: node_mksnapshot segfaults during build: LD_LIBRARY_PATH=/tmp/pobj/node-18.12.1/node-v18.12.1/out/Release/lib.host:/tmp/pobj/node-18.12.1/n ode-v18.12.1/out/Release/lib.target:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd ../.; mkdir -p /tmp /pobj/node-18.12.1/node-v18.12.1/out/Release/obj/gen; "/tmp/pobj/node-18.12.1/node-v18.12.1/out/Rele ase/node_mksnapshot" "/tmp/pobj/node-18.12.1/node-v18.12.1/out/Release/obj/gen/node_snapshot.cc" LD_LIBRARY_PATH=/tmp/pobj/node-18.12.1/node-v18.12.1/out/Release/lib.host:/tmp/pobj/node-18.12.1/n ode-v18.12.1/out/Release/lib.target:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd ../.; mkdir -p /tmp /pobj/node-18.12.1/node-v18.12.1/out/Release/obj.target/deps/openssl; python tools/copyfile.py ./dep s/openssl/nodejs-openssl.cnf "/tmp/pobj/node-18.12.1/node-v18.12.1/out/Release/obj.target/deps/opens sl/openssl.cnf" Segmentation fault (core dumped) gmake[1]: *** [node.target.mk:13: /tmp/pobj/node-18.12.1/node-v18.12.1/out/Release/obj/gen/node_snap shot.cc] The backtrace points at out/Release/obj.target/v8_snapshot/geni/embedded.S a generated assembly file with the usual data in .text issue. I have not yet figured out where that file comes from (how it is generated). #0 0x000007c977e5c790 in Builtins_CreateDataProperty () [Current thread is 1 (process 220492)] (gdb) bt #0 0x000007c977e5c790 in Builtins_CreateDataProperty () #1 0x000007c977e00123 in Builtins_CopyDataProperties () #2 0x000007c977ef26c2 in Builtins_InvokeIntrinsicHandler () #3 0x000007c977dd8a90 in Builtins_InterpreterEntryTrampoline () bypassed with USE_NOEXECONLY in this build. The resulting firefox works fine. lang/pypy Bootstrap segfaults. Backtrace is useless. Perhaps possible to generate a bootstrap with USE_NOEXECONLY and see if that's enough. [PyPy 7.3.1 with GCC OpenBSD Clang 13.0.0] [platform:msg] Set platform with 'host' cc=None, using cc='cc', version='Unknown' [translation:info] Translating target as defined by targetpypystandalone Segmentation fault (core dumped) x11/qt5/qtwebengine Uses broken BoringSSL sha256 asm at build time. Fix for this and other amd64 asm on ports. Unfortunately, at least the V8 engine emits x-only violating assembly, so this fix alone is not good enough.
