Cannot find module with tag 'cpufeatures' in import path

[gpakosz]

I have a project that has been working from Android NDK r4.

The project used to import the cpufeatures module. As part of opening this issue, I discovered documentation has likely changed over time and nowadays tells users to import android/cpufeatures by appending $(call import-module,android/cpufeatures) to Android.mk.

Anyways, when transitioning to NDK r11 or r11b and when doing it the old (likely erroneous) way and calling $(call import-module,cpufeatures) while APP_ABI being set to armeabi-v7a, I'm getting the following error:

Android NDK: /path/to/Android.mk: Cannot find module with tag 'cpufeatures' in import path
Android NDK: Are you sure your NDK_MODULE_PATH variable is properly defined ?
Android NDK: The following directories were searched:
Android NDK:

However, everything goes fine when compiling with APP_ABI=armeabi-v7a-hard.

In my case, the resolution is to use $(call import-module,android/cpufeatures) instead of $(call import-module,cpufeatures). However, the observed difference between APP_ABI=armeabi-v7a and APP_ABI=armeabi-v7a-hard makes me believe there's something to look into ndk-build internals in order to figure out why behavior is different.

[DanAlbert]

I don't see any difference in behavior between ABIs. My Android.mk is just:

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE := bar
LOCAL_SRC_FILES := bar.cpp
LOCAL_STATIC_LIBRARIES := libcpufeatures
include $(BUILD_SHARED_LIBRARY)

$(call import-module,cpufeatures)

I'll leave this open to give you a chance to respond. If you have an example failing case, I'll take a look.

[gpakosz]

You are right, this has nothing to do with ABIs. Here's my setup:

→ ~/chance ls -l /opt/
lrwxr-xr-x   1 root    wheel   16 Mar 21 21:05 android-ndk -> android-ndk-r11b

→ ~/chance tree .
.
├── Android.mk
└── Application.mk

→ ~/chance cat Android.mk
CAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE := bar
LOCAL_SRC_FILES := bar.cpp
LOCAL_STATIC_LIBRARIES := libcpufeatures
include $(BUILD_SHARED_LIBRARY)

$(call import-module,cpufeatures)

→ ~/chance cat Application.mk
LOCAL_PATH := $(call my-dir)

APP_BUILD_SCRIPT := $(LOCAL_PATH)/Android.mk

→ ~/chance /opt/android-ndk/ndk-build NDK_APPLICATION_MK=./Application.mk NDK_PROJECT_PATH=$PWD
Android NDK: Android.mk: Cannot find module with tag 'cpufeatures' in import path
Android NDK: Are you sure your NDK_MODULE_PATH variable is properly defined ?
Android NDK: The following directories were searched:
Android NDK:
Android.mk:9: *** Android NDK: Aborting.    .  Stop.

However, when I use $(call import-module,android/cpufeatures) then I stop having that error about cpufeatures module not being found and build moves on looking for bar.cpp

make: *** No rule to make target `/opt/android-ndk-r11b/sources/cxx-stl/system/bar.cpp', needed by `obj/local/armeabi/objs/bar/bar.o'.  Stop.

(which in the current setup I quite don't get why it looks for bar.cpp in /opt/android-ndk-r11b/sources/cxx-stl/system but well that's another story...)

So in the end, do you know when the contract of import-module changed? What I could confirm is that from r9c to r10e, the Android.mk file from samples/hello-neon/jni/Android.mk contains $(call import-module,cpufeatures) and not $(call import-module,android/cpufeatures).

[DanAlbert]

However, the observed difference between APP_ABI=armeabi-v7a and APP_ABI=armeabi-v7a-hard makes me believe there's something to look into ndk-build internals in order to figure out why behavior is different.

Sorry, this is the part I was actually responding to.

So in the end, do you know when the contract of import-module changed? What I could confirm is that from r9c to r10e, the Android.mk file from samples/hello-neon/jni/Android.mk contains $(call import-module,cpufeatures) and not $(call import-module,android/cpufeatures).

https://android.googlesource.com/platform/ndk/+/master/sources/cpufeatures/README.TXT

I suppose the wording there might actually mean that it was specifically the header that was deprecated and not the path itself (I had read it after the note in the Android.mk, so I thought it meant that path was deprecated as well).

With this already having shipped, and no plan for another hotfix, putting those files back wouldn't be in a stable release for another few months. I'm not sure there's any value in doing it if the fix is just to change cpufeatures to android/cpufeatures.