Как правильно поддерживать различные C ++ STL в собственных сборках Android - PullRequest
Новая
       36

Как правильно поддерживать различные C ++ STL в собственных сборках Android

0 голосов
/ 09 июля 2019

Если честно, я понял, что все зависимости c ++ должны быть скомпилированы с тем же C ++ STL & Ndk в Android Project, как указано здесь .но что, если у меня много зависимостей с поддержкой различных версий C ++ STL и NDK.Похоже, это бесполезно.Я считаю, что для этого должен быть правильный путь.

Во-первых, ситуация такова, что существует проект Android, который собирается со многими библиотеками c ++ (их может быть больше 3).Это поддерживает разные C ++ STL и Ndk.Каким-то образом эти зависимости работали, пока не решили пересоздать для некоторых целей.Например, сборка старой версии поддержки v8 (v4.9) stlport , POCO поддерживает gnustl и т. Д.

Кстати, я уже пробовал;

  • Построение зависимостей с определенным STL (сбой)
  • Добавление разных STL в качестве общих библиотек к таким зависимостям, как (Android.mk);
    include $(CLEAR_VARS)
LOCAL_MODULE := stlportshared
LOCAL_SRC_FILES := $(LOCAL_PATH)/../../../src/main/jniLibs/$(TARGET_ARCH_ABI)/libstlport_shared.so
include $(PREBUILT_SHARED_LIBRARY)

include $(CLEAR_VARS)
ifeq ($(TARGET_ARCH_ABI),x86)
    LOCAL_SRC_FILES := $(LOCAL_PATH)/../../../libsnative/x86/release/libv8-7dc15a4d5e.a
else
    LOCAL_SRC_FILES := $(LOCAL_PATH)/../../../libsnative/armeabi/release/libv8-7dc15a4d5e.a
endif
LOCAL_MODULE := v8
LOCAL_SHARED_LIBRARIES := stlportshared
include $(PREBUILT_STATIC_LIBRARY)

Фактический APP_STL gnustl_shared в Application.mk

Примечание. Ошибка компиляции отсутствует, но происходит сбой среды выполнения.Сбой null разыменования .Предназначен, чтобы спросить, как поверхностный, но я могу переслать подробности о сбоях для тех, кому любопытно.

1 Ответ

0 голосов
/ 13 июля 2019

Прежде всего, есть очень веские причины использовать последнюю версию NDK. На момент написания этой статьи r20, к счастью, поддерживает только два варианта STL: c ++ _ shared и c ++ _ static .

Самый простой способ организовать ваши нативные библиотеки - собрать их все с помощью c ++ _ shared .

Я понимаю, что вы столкнулись с некоторыми проблемами при таком подходе. Исправление этих проблем может быть полезно в долгосрочной перспективе, потому что эти проблемы могут быть признаками некоторых внутренних проблем в вашем коде.

Но если вы не можете, не отчаивайтесь.

Ваше приложение может безопасно использовать различные библиотеки mative, каждая из которых построена на своем собственном STL, если оно не смешивает эти нативные библиотеки. Если у вас есть класс Java A , который имеет собственные методы в libA.so и класс B со своим собственным libB.so , и там нет вызовов от libA.so до libB.so или наоборот, вам не важно, какой STL используется libA.so , а какой - libB.so .

Кроме того, если у вас есть собственная библиотека libQ.so, которая вызывает функции C в libP.so, вам все равно, будет ли libP или libQ вообще использовать STL, или какой STL использует каждый из них. Но это верно, если эти функции C не являются скрытыми функциями C ++. Они не должны передавать объекты C ++ (включая std :: string ). Они не должны получать или возвращать указатели на объекты C ++ (даже если C API использует reinterpret_cast для void *.

Обратите внимание, что для большинства практических целей правила для библиотек, построенных с c ++ _ static , одинаковы. Две такие библиотеки не должны передавать объекты C ++ от одного к другому.

...