2

私の具体的な問題は、1 つの共有ライブラリ (JNI インターフェイス) と 2 つの静的ライブラリを持つプロジェクトで、Android の「cpufeatures」ライブラリ (NDK の docs/CPU-FEATURES.html に記載) を使用する必要があることでした。

共有ライブラリは cpufeatures ライブラリを直接使用するのではなく、静的ライブラリの 1 つの内部で使用されます。

cpufeatures は Android の「インポート モジュール」です。インポート モジュールの使用はかなり簡単で、次の手順のみが必要です (NDK の r8e バージョンの CPU-FEATURES.html から)。

次のように、静的ライブラリの依存関係のリストに「cpufeatures」をリストします。

LOCAL_STATIC_LIBRARIES := cpufeatures

Android.mk の最後に、次のように「android/cpufeatures」モジュールをインポートします。

$(call import-module,android/cpufeatures)

ソース コードに、次の名前のヘッダーを含めます。

ただし、メイン ライブラリの LOCAL_STATIC_LIBRARIES に cpufeatures を追加すると、cpufeatures のインクルード パスは、スタティック ライブラリのビルド時ではなく、メイン ライブラリのビルド時にのみ使用できるため、コンパイルは失敗します。

cpufeature の Android.mk の内容とこの関連する回答は、次のように代わりに共有ライブラリ自体に LOCAL_STATIC_LIBRARIES を追加しても問題ないことを示しています。

...
include $(CLEAR_VARS)

LOCAL_MODULE := CommonClasses
LOCAL_CFLAGS := $(MY_CFLAGS)
LOCAL_C_INCLUDES += $(MY_COMMON_C_INCLUDES)
LOCAL_STATIC_LIBRARIES := cpufeatures

LOCAL_SRC_FILES := \
$(wildcard $(MY_COMMON_CLASSES_SRC_PATH)/*.cpp) \
...
$(wildcard $(MY_COMMON_CLASSES_SRC_PATH)/sound/*.cpp)

include $(BUILD_STATIC_LIBRARY)
...

$(call import-module,android/cpufeatures)

実際、それは機能します。スタティック ライブラリの一部としてコンパイルされたソース ファイルに、次のようなライブラリのヘッダーを含めることができるようになりました。

#include <cpu-features.h>

私が尋ねている理由は、静的ライブラリを別の静的ライブラリにリンクすることはほとんど意味がないからです。ただし、LOCAL_STATIC_LIBRARIES のセマンティクスはより抽象的なようです。

これは正しい方法ですか?つまり、これが引き続き機能し、後で予期しない苦情が発生しないと期待できますか?

4

0 に答える 0