老实说,我理解所有c++依赖项都必须使用相同的c++STL&Ndk在Android项目中,如这里所示。但是如果我有很多依赖项,支持不同的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在Application.mk 中是gnustl_shared
注意:没有编译错误,但运行时崩溃。崩溃是空引用。本想问得很肤浅,但我可以为好奇的人转发车祸的细节。
首先,使用最新版本的NDK有非常充分的理由。r20,幸运的是,它只支持两个STL变体:c++_shared和c++_static。
组织本机库的最简单方法是使用c++_shared构建所有库。
我知道你在这种方法上遇到了一些问题。从长远来看,修复这些问题可能会有所帮助,因为这些问题可能是代码中某些内部问题的症状。
但如果你做不到,就不要冷静。
你的应用程序可以安全地使用不同的匹配库,每个库都有自己的STL,只要它不混合这些本地库。如果您的Java类A在libA.so中具有本机方法,并且类B具有自己的libB.soibA.so到libB.so的调用,或者反之亦然,那么您不应该关心librA.soibB.so[/strong>使用哪个STL。
此外,如果您有在libP.so中调用C函数的本地库libQ.so,那么您根本不在乎libP或libQ是否使用STL,也不在乎它们各自使用哪个STL。但如果这些C函数不是伪装的C++函数,这是真的。它们不应该传递C++对象(包括std::string)。它们不应该接收或返回指向C++对象的指针(即使C API对void*使用relpret_cast
请注意,出于大多数实际目的,使用c++_static构建的库的规则是相同的。两个这样的库不应该将C++对象从一个传递到另一个。