3

由于我有一个处理密集型应用程序，我想构建一个支持NEON / Advanced SIMD的变体。另外我有多个带有算法的源文件，所以我不想分别为每个文件启用霓虹灯。以下是重要部分Android.mk：

ifeq ($(TARGET_ARCH_ABI),armeabi-v7a)

include $(CLEAR_VARS)
# Build Advanced SIMD variant
LOCAL_MODULE            := mymod-neon
LOCAL_ARM_NEON          := true
LOCAL_ARM_MODE          := $(MY_ARM_MODE)
LOCAL_SRC_FILES         := $(MY_SRC_FILES)
LOCAL_C_INCLUDES        := $(MY_C_INCLUDES)
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_C_INCLUDES)
LOCAL_SHARED_LIBRARIES  := $(MY_SHARED_LIBRARIES)
include $(BUILD_SHARED_LIBRARY)

endif

include $(CLEAR_VARS)
# Build regular variant
LOCAL_MODULE            := mymod
LOCAL_ARM_MODE          := $(MY_ARM_MODE)
LOCAL_SRC_FILES         := $(MY_SRC_FILES)
LOCAL_C_INCLUDES        := $(MY_C_INCLUDES)
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_C_INCLUDES)
LOCAL_SHARED_LIBRARIES  := $(MY_SHARED_LIBRARIES)
include $(BUILD_SHARED_LIBRARY)

我尝试为ARMv7a构建 2 个库，但遗憾的是，由于使用了“高级”Makefile 工具，我无法编译 2 个不同的库。

它覆盖了.o目标：

/android-ndk/build/core/build-binary.mk:272: warning: overriding commands for target `obj/local/armeabi-v7a/objs/myalg.o'

可悲的是，我还没有找到一种方法来强制构建霓虹灯对象objs-neon而不是obj.

有什么办法可以优雅地解决这个问题吗？

4

2 回答 2

1

我最终做的是将我们的符号链接src到src-neon目录并通过以下方式访问所有霓虹灯源src-neon：

ifeq ($(TARGET_ARCH_ABI),armeabi-v7a)

include $(CLEAR_VARS)
# Build Advanced SIMD variant
LOCAL_MODULE            := mymod-neon
LOCAL_ARM_NEON          := true
LOCAL_ARM_MODE          := $(MY_ARM_MODE)
LOCAL_SRC_FILES         := $(call get_sources,`src-neon`)
LOCAL_C_INCLUDES        := $(MY_C_INCLUDES)
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_C_INCLUDES)
LOCAL_SHARED_LIBRARIES  := $(MY_SHARED_LIBRARIES)
include $(BUILD_SHARED_LIBRARY)

endif

include $(CLEAR_VARS)
# Build regular variant
LOCAL_MODULE            := mymod
LOCAL_ARM_MODE          := $(MY_ARM_MODE)
LOCAL_SRC_FILES         := $(call get_sources,`src`)
LOCAL_C_INCLUDES        := $(MY_C_INCLUDES)
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_C_INCLUDES)
LOCAL_SHARED_LIBRARIES  := $(MY_SHARED_LIBRARIES)
include $(BUILD_SHARED_LIBRARY)

幸运的是，我们很早就决定只在 Unix 机器上工作，所以这对我们来说是一个可行的选择。

于 2013-04-08T06:04:57.300 回答
0

是的，ndk-build 应该通过调试和非调试以及 ISA 分隔中间对象，所以实际上我认为，正如其他人指出的那样，您可能在其他地方有错误。请注意，ndk-build 将按 ISA 和调试/非调试分隔中间对象，而不是模块名称。因此，如果多个模块尝试构建同一个文件，您可能会遇到问题。

话虽如此，我要指出您可能会以稍微错误的方式处理此问题，因为armeabi-v7a这并不意味着支持 NEON。虽然 ARM 确实在 v7a 中引入了 NEON，但它是供供应商添加的可选协处理器，因此 v7a 处理器可能没有 NEON 协处理器。所以不幸的是，有了这些信息，你又回到了原点……

这个问题确实有一点重复，在这里：

Android 构建系统、NEON 和非 NEON 构建

此外，NDK 构建文档确实为此专门写了一页。查看您的 android-ndk-r8e/documentation.html，左侧有一个指向“CPU ARM Neon”的链接

他们指出的一件事是，最好的方法是通过 CPU 调度，但他们还向您展示了如何使用 .neon 额外文件扩展名将源文件标记为霓虹灯和非霓虹灯。恕我直言，将不同的 CPU 代码放在不同的源文件中总是好的，不管构建系统是什么，因为你可以删除很多丑陋的预处理器的东西。我猜这是一种最佳实践，这就是 NDK 所支持的。

毕竟，我看到你最终得到了 LCID Fire 的解决方案。您使用略有不同的源文件构建不同的库。您实际上应该有 3 个不同的库，一个用于非 v7a，一个用于带有 neon 的 v7a，一个用于不带 neon 的 v7a。

于 2013-05-09T19:39:50.987 回答