GCC Deprecated on Android - switch default toolchain from gcc to clang/llvm

[Brahmasmi]

Starting with r11, Android NDK has deprecated gcc and made clang/llvm the default for Android. Also, gcc will not be updated beyond 4.9.

As such, could we please update to clang/llvm as the default?

For more information, please refer to https://developer.android.com/ndk/downloads/revision_history.html - click on Android NDK, Revision 11 (March 2016).

Clang

        Important announcements
            We strongly recommend switching to Clang.
                If you experience problems with Clang, file bugs here for issues
                specific to Clang in the NDK. For more general Clang issues, file
                bugs by following the instructions on this page.
...
...
GCC

        Important announcements
            GCC in the NDK is now deprecated in favor of Clang.
                The NDK will neither be upgrading to 5.x, nor accept non-critical
                backports.
                Maintenance for miscompiles and internal compiler errors in 4.9
                will be handled on a case by case basis.

[joesavage]

I agree that this would be a good change, however I'm not sure how easy it would be to make the transition. For starters, it doesn't look like clang supports all the ARM assembler syntax that is used in this project (at least, this is one of the immediate problems I ran into when trying to get things working with clang on my machine -- I'm certainly no expert in this area, however).

EDIT: Actually, taking a closer look, this might be easier than I had thought. It seems that ios_config.cmake already uses clang, and the script gas2ios_convert.py already exists to take convert the GAS ARM assembly used in the project to a format that clang supports. By copying most of the build configuration for IOS_PLATFORM, I'm able to get things compiling on Linux using clang, and I suspect the same can be done for Android with relative ease.

[h6ah4i]

Hi. I have succeeded to build Ne10 with clang. Try the following procedure😄

1. Tweak Ne10/CMakeList.txt

Comment out these 3 lines in Ne10/CMakeList.txt

diff --git a/CMakeLists.txt b/CMakeLists.txt
index fc2a5e3..65e0cc4 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -110,11 +110,11 @@ if(ANDROID_PLATFORM)
     endif()

     #TODO: Fine tune pic and pie flag for executable, share library and static library.
-    set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} --sysroot=${NDK_SYSROOT_PATH} -pie")
+#    set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} --sysroot=${NDK_SYSROOT_PATH} -pie")

     # Adding cflags for armv7. Aarch64 does not need such flags.
     if(${NE10_TARGET_ARCH} STREQUAL "armv7")
-        set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mthumb-interwork -mthumb -march=armv7-a -mfloat-abi=${FLOAT_ABI} -mfpu=vfp3")
+#        set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mthumb-interwork -mthumb -march=armv7-a -mfloat-abi=${FLOAT_ABI} -mfpu=vfp3")
         if(NE10_ARM_HARD_FLOAT)
             # "--no-warn-mismatch" is needed for linker to suppress linker error about not all functions use VFP register to pass argument, eg.
             #   .../arm-linux-androideabi/bin/ld: error: ..../test-float.o
@@ -122,7 +122,7 @@ if(ANDROID_PLATFORM)
             # There is call convension mismatch between NDK's crt*.o and ne10's object files.
             # crt*.o still uses softfp while ne10's object files use hard floating point.
             # Refer $NDK/tests/device/hard-float/jni/Android.mk for more details.
-            set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wl,--no-warn-mismatch")
+#            set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wl,--no-warn-mismatch")
         endif()
         # Turn on asm optimization for Android on ARM v7.
         set(NE10_ASM_OPTIMIZATION on)

2. Add CMake toolchain file

Save the following code snippet into Ne10/Android_config.cmake

set(CMAKE_SYSTEM_NAME Linux)

set(ANDROID_PLATFORM ON)
set(ANDROID_API_LEVEL 14)
set(NE10_ANDROID_TARGET_ARCH armv7)

set(ANDROID_TOOLCHAIN clang)
set(ANDROID_PLATFORM "android-${ANDROID_API_LEVEL}")
include("$ENV{ANDROID_NDK}/build/cmake/android.toolchain.cmake")

# Skip the platform compiler checks for cross compiling
set(CMAKE_CXX_COMPILER_WORKS TRUE)
set(CMAKE_C_COMPILER_WORKS TRUE)
set(CMAKE_ASM_COMPILER_WORKS TRUE)

set(NE10_BUILD_UNIT_TEST "Build NE10 unit test" ON)
set(NE10_SMOKE_TEST "Run smoke test" ON)
set(NE10_REGRESSION_TEST "Run regression test" ON)
set(NE10_PERFORMANCE_TEST "Run performance test" ON)

3. Build

cd Ne10
mkdir build && cd build
export ANDROID_NDK=$HOME/Android/sdk/ndk-bundle  # modify this line to NDK installed dir
cmake -DCMAKE_TOOLCHAIN_FILE=../Android_config.cmake  ..
make -j4

---

EDIT:

If PIE binary is required;

1. Merge PR #84
2. set ANDROID_API_LEVEL to 16 or grater OR specify ANDROID_PIE = TRUE.

[Brahmasmi]

Caveat - I am not an expert on compilers/architectures/assembly.

I filed a bug report on the android NDK issue list (android-ndk/ndk#111) because the compilation barfed on -mthumb-interwork when switching from gcc to clang. It is currently open and tagged with a "clang" tag. So I dropped the idea of switching to clang. Please refer to the bug report for detailed information.

As such, I am not sure whether removing the -mthumb-interwork and other flags is the right way forward.

To be honest, I am now of the belief that the NDK guidance to switch to clang was made in good faith but lacked sufficient foresight - atleast till the NDK folks sort out the clang issues. IMHO, I do not know whether their actions inspire confidence. They added arm-v7a-hard in one NDK release, were praised for it (http://blog.alexrp.com/2014/02/18/android-hard-float-support/) but then removed it later with a justification which questioned the very introduction of it (https://android.googlesource.com/platform/ndk/+/ndk-r12-release/docs/HardFloatAbi.md). As another example, it was suggested in my bug report discussion that -mthumb-interwork was meaningless for android. I had to point out that an NDK engineer had indicated in an ndk google group thread that -mthumb-interwork was required for ABI compatibility and that -mthumb-interwork found mention in countless posts on the group. Again, I am not an expert and could be completely wrong on this.

[joesavage]

Having had a closer look at this, I'm fairly sure that, from Ne10's perspective, the -mthumb-interwork flag is useless (see #143). We target ARMv7 and above, and so — as indicated here in the issue you opened for the NDK — we shouldn't need this flag.

[Brahmasmi]

@joesavage @h6ah4i

Do you folks think I should close this issue, in case it is not relevant anymore?

[rahulrsppp]

Hi,

I am working on camera with OpenCV. I am using NDK 18 on Android Studio 3.0.1. My Application.mk file have code:

APP_STL := c++_static APP_CPPFLAGS := -frtti -fexceptions APP_ABI := armeabi-v7a APP_PLATFORM := android-16 APP_OPTIM := release

but i am still getting error of using CLANG in place of GCC.

Please tell how to use CLANG in place of GCC.

[truefedex]

Can anyone who knows preapre instruction how to build with clang for android latest release version of Ne10 (v1.2.1 at now)? I tried instructions from h6ah4i, comment from Oct 15, 2016 and there a lot of errors during compilation UPD: I checked master last commit and there the same: many errors like error: invalid instruction VBSL qMask,qCoeff,qZero ...and so on (many "invalid instruction" errors)

[jordyjwilliams]

Also having similar issues, get to building NE10_fir.neon.s.o then get loads of errors. error: unexpected token in argument list, error: register expected, error: invalid instruction.

Any advise as to how to compile and build successfully on clang?

[triplef]

I’m seeing the same issues as @jordyjwilliams – lot’s of errors in NE10_fir.neon.s.

Here’s a little outtake of the errors – any ideas?

Ne10/modules/dsp/NE10_fir.neon.s:94:10: error: unexpected token in argument list
qInp .qn Q0.F32
         ^
Ne10/modules/dsp/NE10_fir.neon.s:95:12: error: unexpected token in argument list
dInp_0 .dn D0.F32
           ^
Ne10/modules/dsp/NE10_fir.neon.s:96:12: error: unexpected token in argument list
dInp_1 .dn D1.F32
           ^
...
Ne10/modules/dsp/NE10_fir.neon.s:1804:21: error: invalid instruction
                    VEOR qZero,qZero
                    ^
Ne10/modules/dsp/NE10_fir.neon.s:1807:27: error: register expected
                    VLD1 {dMaskTmp_0,dMaskTmp_1},[pY]
                          ^
Ne10/modules/dsp/NE10_fir.neon.s:1881:27: error: register expected
                    VLD1 {dCoeff_0[],dCoeff_1[]},[pCoeffs]!
                          ^
...

It sounds like @Phillip-Wang was running into the same issue in https://github.com/projectNe10/Ne10/issues/228#issuecomment-485442359 and fell back to using intrinsics in PR #231.

[jordyjwilliams]

@VODU this is where I got to android ne10 wise