J'essaie de créer une bibliothèque statique en utilisant les derniers NDK Android (R5) et je n'ai aucune chance. J'ai été capable de construire et de gérer les échantillons (par exemple, Hellojni) sans aucun problème, mais de commencer un nouveau projet de «Scratch» a été une histoire différente.
Pour cette expérience, j'essaie de construire libpng. Ma structure de dossiers ressemble à ceci: donc j'ai deux Android.mks. Un pour construire tous les sous-projets et un pour le sous-projet de libpng. root / jni / png / android.mk ressemble à ceci: Cette configuration de construction semble ne rien faire (c.-à-d. L'exécution de NDK-Build à partir du dossier racine ne fait rien, même après une NDK-Build Clean). Une exécution verbeuse (NDK-Build V = 1) montre des appels RM -F (supprimant des dossiers inexistants) mais rien ne correspond au projet ou au sous-projet. Je suis assez intéressé par la raison pour laquelle ce script de construction échoue, mais le processus aurait dû être trivial, donc je suis certain que rien n'est terriblement intéressant. Je suis beaucoup plus intéressé par la façon dont je pourrais commencer à attaquer les bugs construire seul. L'appel d'écho dans le script ci-dessus n'est jamais frappé - je ne sais pas comment déterminer quelles valeurs sont ou pourquoi elle saute le sous-projet. Quelqu'un a-t-il trouvé une façon de savoir ce que le système de construction est essayer faire? Je serais également intéressé à savoir s'il y a des documents pour ces outils ou si c'est juste le poignée de fichiers texte dans le dossier Docs de la NDK? J'ai essayé de résoudre ce problème en copiant des morceaux d'androïde aléatoire.mk que j'ai trouvé de googling autour, mais seules les quelques commandes utilisées dans les simples échantillons NDK semblent être documentées. L'expérience a donc réellement augmenté de nouvelles questions. < / p>
3 Réponses :
Je recommanderais de me débarrasser du module_path et de ne pas essayer d'utiliser le caractère générique: je n'ai pas vraiment vu ce travail à droite.
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := png LOCAL_SRC_FILES := pngget.c pngread.c pngrutil.c pngtrans.c pngwtran.c png.c pngmem.c pngrio.c pngset.c pngwio.c pngwutil.c pngerror.c pngpread.c pngrtran.c pngwrite.c LOCAL_C_INCLUDES := png.h pngconf.h pngpriv.h include $(BUILD_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := png2 LOCAL_STATIC_LIBRARIES := png include $(BUILD_SHARED_LIBRARY)
Merci. J'ai essayé cela et cela n'a changé aucun des comportements (NDK-Build est toujours un non-OP). J'ai aussi essayé de supprimer local_c_includes, comme je ne peux pas savoir pourquoi cela serait utilisé. Pas de chance. On dirait que vous suggérez que j'utilise Eclipse pour générer ce fichier MK? Je ne savais pas que tu pouvais faire ça. Je pourrais peut-être utiliser cela au lieu d'instructions sur la manière de déboguer des fichiers .mk. Pouvez-vous me signaler aux instructions sur la façon de faire cela?
Impair: désolé que cela ne fonctionnait pas. Le fichier de référence d'origine a été généré à la main, mais construit par Eclipse à moins que je me souvienne de mal. Je vais essayer de le construire moi-même. Une chose à noter: Si vous faites cela sous Windows, vous devez vous assurer qu'il n'y a pas d'espaces dans vos chemins, comme en quelque sorte ou l'autre après plus d'une décennie Cygwin ne peut toujours pas gérer correctement les espaces (pas que le studio visuel DDK fait un travail écrasant, de sorte que peut être vent de sucer Windows).
Je vais essayer de supprimer ma structure de dossiers et d'utiliser votre fichier Verbatim. Mais la question initiale, sur la manière de déboguer ces fichiers .mk, tiendrait toujours. FYI, je suis sur un Mac ...
Hehe: C'est vraiment une vraie magie. Les documents des outils sont dans
Vous êtes mon nouveau héros. La modification, sur le maquillage nécessitant une dépendance, résolvée. Je suis convenablement gêné. Merci beaucoup!
J'ai passé des heures à essayer de déterminer pourquoi ma bibliothèque statique ne compilait pas. La dépendance libérée partagée a fait l'affaire! Je (et quels cheveux je suis partis) merci!
J'ai le même problème. Mais d'une manière ou d'une autre, cela ne fonctionne toujours pas. J'utilise NDK R7, peut-être que c'est encore plus brisé maintenant. Heureusement, il semble exister une solution de voies à outils autonome (voir NDK / DOCS / TOOLCHAINE.HTML). J'espère que cela me donnera la flexibilité dont j'aurai besoin.
Je me suis battu sur la tête avec ce problème pendant les deux dernières heures, et ce post a aidé à résoudre le résoudre. Plutôt que d'ajouter une dépendance factice, invoquerez simplement NDK-Build (qui est juste une fine emballage sur la marque) comme «NDK-Build png».
J'ai trouvé que lorsque j'ai ajouté une bibliothèque partagée "factice" comme décrit dans la modification, la .a (que j'ai trouvée à Obj /, impliquant que c'était un détail interne) ne contenait aucun des fichiers .O voulu.
En outre, le .so a recompilé tous les fichiers qui auraient été construits pour la bibliothèque statique. Donc, il était senti logiciel que le .a était vide.
Qu'est-ce qui m'a aidé à ajouter une ligne App_Modules à ma candidature.mk, comme décrit dans Impossible de construire une bibliothèque statique avec Android NDK R8 . Vous voulez probablement une application.mk quand même, car il contient d'autres paramètres importants pour votre Static Lib, comme app_stl, app_platform, app_abi, etc.