Building ARMv7a regular and neon at the same time

Question

Since I have a very processing intensive App I would like to build a variant with NEON / Advanced SIMD support. Also I have multiple source files with algorithms, so I don't want to enable neon for every file separately. Following the important part of the 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)

I tried to build 2 libraries for ARMv7a, but sadly since using the "advanced" Makefile tool, it doesn't get that I am compiling 2 different libraries.

It overrides the .o target:

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

Sadly I have not found a way to force the neon objects being built in objs-neon instead of obj.

Is there any way one can resolve this in an elegant matter?

for me, your Android.mk builds `obj/local/armeabi-v7a/objs/mymod/myalg.o` and obj/local/armeabi-v7a/objs/mymod-neon/myalg.o`. Maybe you override `NDK_APP_OUT` somewhere? — Alex Cohn, Apr 07 '13 at 18:03
NEON is a runtime option in Android. It would take a lot of extra work to make two ARMv7A binaries live together. I create fat binaries with ARMv5 and ARMv7A and in the ARMV7A build I test the runtime option of NEON and use it if it's there. if (android_getCpuFamily() == ANDROID_CPU_FAMILY_ARM && (android_getCpuFeatures() & ANDROID_CPU_ARM_FEATURE_NEON) != 0) — BitBank, Apr 07 '13 at 21:16
@AlexCohn But that only works if you have two distinct src directories. For me they both point to `$(MY_SRC_FILES)`. — abergmeier, Apr 08 '13 at 05:00
Maybe, you are using an ancient version of NDK? Today's choice is r8e! Note that in my case, the object is under `$(LOCAL_MODULE)` subdirectory of `obj/local` — Alex Cohn, Apr 08 '13 at 10:34

score 1 · Answer 1 · answered Apr 08 '13 at 06:04

What I ended up doing was to symlink our src to src-neon directory and access all neon sources via 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)

Lucky for us, we did decide early on to only work on Unix machines so this is a viable option for us.

score 0 · Answer 2 · edited May 23 '17 at 12:21

Yes, ndk-build should separate the intermediate objects by debug and non-debug and ISA, so actually I think, as other people pointed out, that you might have an error somewhere else. Note that ndk-build will separate the intermediate objects by ISA and debug/non-debug, but not module name. So if multiple modules try to build the same file, you probably will have issues.

Having said that, I would point out that you might be going about this in slightly the wrong way since armeabi-v7a does not imply NEON support. Although ARM did introduce NEON with v7a, it is an optional co-processor for vendors to add, so v7a processors may not have a NEON co-processor. So unfortunately, with this info, you are back to square one...

This question does have a bit of a duplicate, here:

Android build system, NEON and non-NEON builds

Furthermore, the NDK build documentation does devote a whole page to this. Look in your android-ndk-r8e/documentation.html, On the left side there is a link to "CPU ARM Neon"

One thing that they point out is that the best way to do this is via CPU dispatching, but they also show you how to tag your source files as neon vs non-neon, using the .neon extra file extension. IMHO, it is always good to put different CPU code in different source files, no matter what the build system because you can remove a lot of ugly pre-processor stuff. This is sort of best-practice I guess, and so that's what NDK supports.

After all of that, I see you end up with LCID Fire's solution. You build different libraries with slightly different source files. You should actually have 3 different libraries, one for non v7a, one for v7a with neon, and one for v7a without neon.

Building ARMv7a regular and neon at the same time

2 Answers2