nodejs / nodejs/node

Android arm64 cross-build fails with current main and NDK r29

Offen
#65,771 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

android
Vorherrschende Sprache
JavaScript
Sterne
122k
Forks
37.3k
Ø Merge
4 T. 2 Std.
Gemergte PRs (30 T.)
283

Beschreibung

Version

Current upstream main at 1e9fd9544ef38e6e36ca1d5ab7af3bab5b20496d

Platform
Android 11 target, arm64, API 30
Android NDK r29
Linux x86_64 build host
What steps will reproduce the bug?

On an unmodified checkout of main:

./android-configure /path/to/android-ndk-r29 30 arm64
make
What do you see instead?

The Android configure script assigns the Android target compiler to CC and
CXX. That compiler is also used for host-side tools such as ICU and V8
generators. The Android zlib target includes the NDK CPU-feature header but
does not include the corresponding sources/android/cpufeatures/cpu-features.c
implementation, which causes the Android CPU feature symbols to be missing
from the link.

Android cross builds can also reach V8 host-tool configurations where the
required POSIX trap-handler sources are not selected. Android trap-handler
activation must remain disabled; the required source selection is a separate
build concern.

Expected behavior

android-configure should select separate host and target compilers, and an
Android arm64 build should complete without requiring local absolute paths or
hand-edited generated files when using NDK r29.

Current status

The follow-up changes are kept separately reviewable:

  1. #65772 separates host and
    target compilers.
  2. #65773 compiles the Android
    NDK CPU feature implementation through a checked-in wrapper.
  3. #65774 selects the required V8
    POSIX and host simulator sources while keeping Android trap-handler support
    disabled.

Validation with NDK r29, Android API 30, and arm64 completed successfully. The
resulting Node binary also passed basic zlib, crypto, Intl, WebAssembly, and
SharedArrayBuffer runtime checks on Android 11.

The issue remains open pending upstream review and CI completion for the three
follow-up pull requests.

Validation notes

Runtime loading used the matching NDK libc++_shared.so alongside the binary
and did not require a system-image change.

The earlier NDK r27d std::atomic_ref compatibility observation is retained
only as historical context. PR #65775 was closed because an ordinary simdutf
API is not an equivalent atomic fallback for SharedArrayBuffer access; it is
not part of the current fix.

The changes are intended to be generic and do not depend on a particular
Android system-image integration, device serial number, or checkout path.

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Beginne mit android-configure und dem Android-zlib-Build-Pfad. Untersuche anschließend die Auswahl des ICU/V8-Generators auf der Host-Seite sowie die Implementierung in sources/android/cpufeatures/cpu-features.c. Prüfe die PRs #65772, #65773 und #65774, bevor du das Problem mit NDK r29, API 30 und arm64 reproduzierst. Als abgeschlossen gilt die Aufgabe, wenn der Build erfolgreich abgeschlossen wird und die aufgeführten Android-Laufzeitprüfungen erfolgreich sind.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
android, c, cpp, javascript
Bereich
build-system, mobile-dev
Issue-Typ
Bug
Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Aktivitätsstatus
Veraltet
Klarheit
Klar beschrieben
Anfängerfreundlichkeit
25/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.