Cross compile node v14.x or v.15.x for android x86_64

Version: v14.15.1 and v15.3.0
Platform: cross compile for androidx86_64. Host (5.4.0-53-generic What goes in core / stdlib.js? #59~18.04.1-Ubuntu SMP Wed Oct 21 12:14:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux). Target (androidx86_64 sdk24)
Subsystem: mksnapshot build fail

What steps will reproduce the bug?

> source android-configure /path_to_ndk x86_64 24
> make -j8

The Android NDK version: Linux 64-bit (x86) r21, download from https://developer.android.com/ndk/downloads

How often does it reproduce? Is there a required condition?

The build always stuck as below state.

What is the expected behavior?

Build without error

What do you see instead?

/usr/bin/g++ -rdynamic -m64 -pthread -m64 -fPIC  -o /node/out/Release/mksnapshot -Wl,--start-group /node/out/Release/obj.host/mksnapshot/deps/v8/src/snapshot/embedded/embedded-empty.o /node/out/Release/obj.host/mksnapshot/deps/v8/src/snapshot/embedded/embedded-file-writer.o /node/out/Release/obj.host/mksnapshot/deps/v8/src/snapshot/embedded/platform-embedded-file-writer-aix.o /node/out/Release/obj.host/mksnapshot/deps/v8/src/snapshot/embedded/platform-embedded-file-writer-base.o /node/out/Release/obj.host/mksnapshot/deps/v8/src/snapshot/embedded/platform-embedded-file-writer-generic.o /node/out/Release/obj.host/mksnapshot/deps/v8/src/snapshot/embedded/platform-embedded-file-writer-mac.o /node/out/Release/obj.host/mksnapshot/deps/v8/src/snapshot/embedded/platform-embedded-file-writer-win.o /node/out/Release/obj.host/mksnapshot/deps/v8/src/snapshot/mksnapshot.o /node/out/Release/obj.host/mksnapshot/deps/v8/src/snapshot/snapshot-empty.o /node/out/Release/obj.host/tools/v8_gypfiles/libv8_base_without_compiler.a /node/out/Release/obj.host/tools/v8_gypfiles/libv8_init.a /node/out/Release/obj.host/tools/v8_gypfiles/libv8_libbase.a /node/out/Release/obj.host/tools/v8_gypfiles/libv8_libplatform.a /node/out/Release/obj.host/tools/icu/libicutools.a /node/out/Release/obj.host/tools/v8_gypfiles/libv8_libsampler.a /node/out/Release/obj.host/tools/v8_gypfiles/libv8_zlib.a /node/out/Release/obj.host/tools/v8_gypfiles/libv8_compiler.a /node/out/Release/obj.host/tools/v8_gypfiles/libv8_initializers.a -Wl,--end-group -ldl -lrt
/node/out/Release/obj.host/v8_base_without_compiler/deps/v8/src/api/api.o: In function `v8::TryHandleWebAssemblyTrapPosix(int, siginfo_t*, void*)':
api.cc:(.text._ZN2v829TryHandleWebAssemblyTrapPosixEiP9siginfo_tPv+0x6): undefined reference to `v8::internal::trap_handler::TryHandleSignal(int, siginfo_t*, void*)'
/node/out/Release/obj.host/v8_base_without_compiler/deps/v8/src/trap-handler/handler-outside.o: In function `v8::internal::trap_handler::EnableTrapHandler(bool)':
handler-outside.cc:(.text._ZN2v88internal12trap_handler17EnableTrapHandlerEb+0x1d): undefined reference to `v8::internal::trap_handler::RegisterDefaultTrapHandler()'
collect2: error: ld returned 1 exit status

Additional information

I noted that in v8_base_without_compiler build config at deps/v8/BUILD.gn, EnableTrapHandler and RegisterDefaultTrapHandler are defined for Linux and x64 platform, but I don't see it generated in out/tools/v8_gypfiles/v8_base_without_compiler.target(host).mk (even I change the condition to always true)

I wonder is this an expected behavior?

I fixed it temporarily by disabling undefined code paths and the node can work normally in the target platform.

diff --git a/deps/v8/src/api/api.cc b/deps/v8/src/api/api.cc
index 3b6226b0f4..9f346bcfc8 100644
--- a/deps/v8/src/api/api.cc
+++ b/deps/v8/src/api/api.cc
@@ -5646,7 +5646,8 @@ bool v8::V8::Initialize(const int build_config) {
 bool TryHandleWebAssemblyTrapPosix(int sig_code, siginfo_t* info,
                                    void* context) {
 #if V8_TARGET_ARCH_X64 && !V8_OS_ANDROID
-  return i::trap_handler::TryHandleSignal(sig_code, info, context);
+  // return i::trap_handler::TryHandleSignal(sig_code, info, context);
+  return false;
 #else
   return false;
 #endif
diff --git a/deps/v8/src/trap-handler/handler-outside.cc b/deps/v8/src/trap-handler/handler-outside.cc
index 1efbc398d0..497cf2894c 100644
--- a/deps/v8/src/trap-handler/handler-outside.cc
+++ b/deps/v8/src/trap-handler/handler-outside.cc
@@ -256,7 +256,8 @@ bool EnableTrapHandler(bool use_v8_handler) {
     return false;
   }
   if (use_v8_handler) {
-    g_is_trap_handler_enabled = RegisterDefaultTrapHandler();
+    // g_is_trap_handler_enabled = RegisterDefaultTrapHandler();
+    g_is_trap_handler_enabled = false;
     return g_is_trap_handler_enabled;
   }
   g_is_trap_handler_enabled = true;

I wonder if there are any further issues if I do this.

Thanks

Any chance this is related to #35520?

I think it's not related, this is more about the linker when building the objects: mksnapshot and the v8_base_without_compiler. I suspect that the handler-inside-posix.o and handler-outside-posix.o is not compiled wiith the v8_base_without_compiler

But when I hard-code to include these objects, It shown a lot of other errors on both the target and host output. I still don't know why.

Btw, I'm new with build systems like GN and GYP. Any hints are welcome.

Thank you.

This seems to have become a 64 bit problem somewhere between 16.10.10 and 16.11.0

See termux/termux-packages#7710. node v16.10.10 compiles for Android aarch64 but not v16.11.0

Update, I was able to fix this error by using this patch

--- ./deps/v8/src/trap-handler/trap-handler.h	2021-10-08 19:08:46.000000000 +0530
+++ ./deps/v8/src/trap-handler/trap-handler.h.mod	2021-10-09 19:43:08.715641214 +0530
@@ -17,22 +17,7 @@
 namespace internal {
 namespace trap_handler {
 
-// X64 on Linux, Windows, MacOS, FreeBSD.
-#if V8_HOST_ARCH_X64 && V8_TARGET_ARCH_X64 &&                        \
-    ((V8_OS_LINUX && !V8_OS_ANDROID) || V8_OS_WIN || V8_OS_MACOSX || \
-     V8_OS_FREEBSD)
-#define V8_TRAP_HANDLER_SUPPORTED true
-// Arm64 (non-simulator) on Mac.
-#elif V8_TARGET_ARCH_ARM64 && V8_HOST_ARCH_ARM64 && V8_OS_MACOSX
-#define V8_TRAP_HANDLER_SUPPORTED true
-// Arm64 simulator on x64 on Linux or Mac.
-#elif V8_TARGET_ARCH_ARM64 && V8_HOST_ARCH_X64 && (V8_OS_LINUX || V8_OS_MACOSX)
-#define V8_TRAP_HANDLER_VIA_SIMULATOR
-#define V8_TRAP_HANDLER_SUPPORTED true
-// Everything else is unsupported.
-#else
 #define V8_TRAP_HANDLER_SUPPORTED false
-#endif
 
 // Setup for shared library export.
 #if defined(BUILDING_V8_SHARED) && defined(V8_OS_WIN)

@thunder-coding

I patched the nodejs on our x86_64 platform and have used it for a year without any problem. Currently, I no longer maintain the build, so I can not help you to test it. Anyway, thanks for your fix @thunder-coding

api.cc

build: rewritten the Android build system

This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.

toolchain: disable V8 trap handler; node's android patch is stale

fix(node-build): force-disable V8 trap handler for android cross build

Navigation Menu

Repository navigation

Cross compile node v14.x or v.15.x for android x86_64 #36287

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior?

What do you see instead?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Cross compile node v14.x or v.15.x for android x86_64 #36287

Description

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior?

What do you see instead?

Additional information

Activity

aduh95 commented on Nov 28, 2020

NhatTanXT3 commented on Nov 30, 2020

thunder-coding commented on Oct 9, 2021

thunder-coding commented on Oct 9, 2021

NhatTanXT3 commented on Oct 21, 2021

guthrietiffany63 commented on Mar 27, 2022

github-actions commented on Jun 27, 2026

github-actions commented on Jul 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions