Cannot find module with tag 'cpufeatures' in import path about ndk HOT 3 CLOSED

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.

from ndk.

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).

from ndk.

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.

from ndk.