Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Fix building jnidispatch with Android NDK 18+ using Clang/LLVM

Ouverte
  • Quelque chose ne va pas ?
#1,659 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
20/100
Type d'issue
Bug
Clarté
À clarifier
Activité
À l'abandon
Stack technique
android, c, java
Domaine
build-system, mobile-dev

Piste de recherche

Commencez par examiner la branche et le commit android-ndk-llvm proposés, puis comparez leurs modifications de build avec la configuration de build actuelle de jnidispatch. Testez le build avec les versions prises en charge d’Android NDK, y compris r27c, et déterminez si la transition de GCC vers Clang fonctionne pour l’ensemble des targets discutés.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

More of a place for discussion than an urgent need to be resolved, I have specifically not made a PR yet as this is nowhere near comprehensively tested. It would be very helpful if anyone with libffi experience in other projects knows about any tricks moving from gcc to clang.

Anyway, here is a branch with my proposed changes: https://github.com/BugsBeGone/jna/commits/android-ndk-llvm/
Actual commit, which may be out of date if branch is rebased to sync with master: https://github.com/BugsBeGone/jna/commit/2be472422f4ea1c479ef1322253b9a1ab7d356e0

Some initial observations:

  • ARMv5 and MIPS (32 & 64) targets were removed in NDK r17. In theory the Play Store still supports versions of Android that could be running on those architectures, so it is a bit soon to drop them entirely if the old toolchains do still work. At the very least I would expect a major JNA version bump to indicate the removed targets (Edit: I guess those libs can always still be built with older NDKs, in which case no need for a breaking change by dropping support).

  • Standalone toolchains are a mess for detecting the version. I cannot think of a way that does not involve the user manually setting either the NDK major version, or a USE_CLANG define to work out which compiler suite to use. I would be in favour of officially not supporting the use of standalone toolchains, as you need approximately 1GB of extra disk space per target, so even testing it is a pain.

  • More to the point, NDKs between r17 & r21 generally seem to be unstable, requiring unholy combinations of GCC/Binutils & Clang/LLVM to work at all. Since the existing build environment has never worked with anything after r15, because of the switch to unified headers, we probably do not need to worry too much so long as everyone is happy to jump from let's say r15 to r22.

I have mostly been testing with NDK r27c, since that was the latest LTS release (Edit: r27d is still the latest LTS, the only differences from r27c are a couple of macOS-specific fixes).

Langage dominant
Java
Étoiles
8.9k
Forks
1.7k
Merge moyen
1 j 13 h
PR mergées (30 j)
1

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de java-native-access/jna

Toutes les issues de java-native-access/jna

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.