合并两个库在安卓 ndk 中不起作用

Question

我在Android NDK中有一个测试应用。以前我能够编译和运行这个应用程序提供的静态库。提供的静态库是"libfulllib.a"。现在我已经编写了包装器函数，并制作了一个包装器函数库，即。"libwrapper.a"。我的工作机器人。Mk文件看起来像这样:

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := rip_test
LOCAL_SRC_FILES := src/rip_test.cpp
LOCAL_CFLAGS := -DCLR_INTERAPTIV_I7 -DCLR_INTERAPTIV -v
LOCAL_C_INCLUDES := 
    $(LOCAL_PATH)/../../RIP/include/ 
    $(LOCAL_PATH)/../../../hardware/libhardware/include/hardware 
    $(LOCAL_PATH)/../../../hardware/libhardware/include 
    $(LOCAL_PATH)/src 
    $(LOCAL_PATH)/../../RIP/inc 
LOCAL_SHARED_LIBRARIES = libsmem.sastra
LOCAL_LDFLAGS := 
    -v 
    -L$(ANDROID_PRODUCT_OUT)/system/lib 
    -lsmem.$(TARGET_BOARD_PLATFORM) 
    -L$(LOCAL_PATH)/../../RIP/library 
    -lwrapper 
    -lfulllib 
    -llog 
    -lcutils 
    -lipc.$(TARGET_BOARD_PLATFORM) 
# this option will build executables instead of building library for
# android application.
include $(BUILD_EXECUTABLE)

这里的包装器是我制作的一个库，它包含了函数的真正定义。现在我不想把fulllib暴露给任何人，所以我去掉了所有的。从wrapper和"fulllib"中创建了一个"all"库。现在是我的机器人。Mk是这样的:

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := rip_test
LOCAL_SRC_FILES := src/rip_test.cpp
LOCAL_CFLAGS := -DCLR_INTERAPTIV_I7 -DCLR_INTERAPTIV -v
LOCAL_C_INCLUDES := 
    $(LOCAL_PATH)/../../RIP/include/ 
    $(LOCAL_PATH)/../../../hardware/libhardware/include/hardware 
    $(LOCAL_PATH)/../../../hardware/libhardware/include 
    $(LOCAL_PATH)/src 
    $(LOCAL_PATH)/../../RIP/inc 
LOCAL_SHARED_LIBRARIES = libsmem.sastra
LOCAL_LDFLAGS := 
    -v 
    -L$(ANDROID_PRODUCT_OUT)/system/lib 
    -lsmem.$(TARGET_BOARD_PLATFORM) 
    -L$(LOCAL_PATH)/../../RIP/library 
    -lall 
    -llog 
    -lcutils 
    -lipc.$(TARGET_BOARD_PLATFORM) 
# this option will build executables instead of building library for
# android application.
include $(BUILD_EXECUTABLE)

我能够编译，但测试应用程序不一样。我想问:这样做安全吗?

两者之间的区别是什么?

Answer 1

合并两个静态库时可能出现的一些问题:

1. 在任意一个库中复制符号。

   如果两个模块都定义了一个函数foo，则未定义将使用哪个函数。即使没有合并库也是如此，但通常会使用找到的第一个符号，如果您重新打包库，使fulllib中的符号现在在wrapper之前，则可能使用不同的定义。

2. 多个同名的。o文件。

   有很多方法可以安全地做到这一点，但这取决于您如何创建liball。A A foo。libfulllib中的O。A可能会覆盖libwrapper中的一个。a(反之亦然)。

这可能不是一个详尽的列表，但这些是我过去遇到的一些问题。