drop the unreachable arm stl libs

[gpakosz]

Hello,

Considering the following setup:

Application.mk:

LOCAL_PATH := $(call my-dir)

APP_BUILD_SCRIPT := $(LOCAL_PATH)/Android.mk

APP_STL := gnustl_shared

Android.mk:

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := foo
LOCAL_ARM_MODE := arm

LOCAL_SRC_FILES += foo.cpp

include $(BUILD_EXECUTABLE)

foo.cpp:

int main()
{
  return 0;
}

Then building with

/opt/android-ndk/ndk-build NDK_APPLICATION_MK=./Application.mk NDK_PROJECT_PATH=.

gives the following output:

[armeabi] Compile++ arm  : foo <= foo.cpp
[armeabi] Prebuilt       : libgnustl_shared.so <= <NDK>/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi/thumb/
[armeabi] Executable     : foo
[armeabi] Install        : foo => libs/armeabi/foo
[armeabi] Install        : libgnustl_shared.so => libs/armeabi/libgnustl_shared.so

Is it a misunderstanding on my part or should the non-thumb version of libgnustl_shared.so be pulled into my project?

If not, is there a variable supposed to be used in order select the thumb vs arm version of the STL?

[DanAlbert]

So, clearly someone tried to make this work: https://android.googlesource.com/platform/ndk/+/master/sources/cxx-stl/gnu-libstdc++/Android.mk#20

But apparently they never tested that the change would work, because that obviously can't work because the user can never affect LOCAL_ARM_MODE for that module. I suppose you could run ndk-build LOCAL_ARM_MODE=arm, but I really doubt that was the intended use case (it would have been named differently if it was).

So, aside from the fact that it doesn't work, why do you want it to work? If we find that, for example, gnustl performs better as arm rather than thumb, we'll just make gnustl always be arm rather than ship both and put the burden on the users...

[gpakosz]

Well, I since you're packaging both arm and thumb versions of the libraries instead of making a choice like what's your suggesting in your last paragraph, I expected it was better to not mix arm and thumb

[DanAlbert]

There's no problem with mixing arm and thumb. Occasionally one may perform better than the other, but it's usually negligible. The only real value is if you're writing your own assembly then you might want one or the other, but that doesn't apply to a library that isn't yours.

I really don't know why that earlier patch was made. Since it doesn't work, I'm probably going to drop the arm versions of the libraries. Going to commandeer this bug to track that.

[DanAlbert]

https://android-review.googlesource.com/c/223416/