New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Android gcc build issues #146

Closed
ziza69 opened this Issue Dec 27, 2016 · 7 comments

Comments

Projects
None yet
2 participants
@ziza69

ziza69 commented Dec 27, 2016

I have run build for Android (latest ndk for Android with gcc 4.9) and I want to tell you what issues I have encountered on the way.

  1. Compiler instantly gives: "error: 'for' loop initial declarations are only allowed in C99 or C11 mode", this is easily fixable if you insert "set(CMAKE_C_FLAGS "-std=c11")"** in CMakeLists.txt.

  2. Gcc does not accept "asm" keyword, and generates rather cryptic error " 'asm' expected before 'asm' (wtf!?)" turns out it should be " __asm__ ". I have solved it by adding "#ifdef GNUC #define asm __asm__"

  3. All "simd" functions (i.e. "test_divc, test_mlac, test_mulc, test_rsbc, test_setc, test_subc, test_mulcmatvec" in "NE10Demo" app for Android) generate SIGSEGV error, I have no idea why, maybe some linker issue?

@joesavage

This comment has been minimized.

Show comment
Hide comment
@joesavage

joesavage Jan 12, 2017

Member

Sorry to hear you're having problems, but thanks for reporting them.

With your first issue, it looks like the compiler is assuming an older C standard for some reason — you're quite right that a std flag should be able to resolve this, though we probably want to use C99 in this case and must be careful that this flag doesn't propagate into the list of C++ flags. The second issue you're experiencing is then related to the first, as using asm within C code is a GNU extension that cannot be used with -std={c99, c11}. We could use __asm__ to fix this as you suggested, but for the time being I'll update the CMakeLists.txt file to use -std=gnu99 instead, resolving both of these issues.

As for your last problem, I'm afraid I have no idea what might be causing this. Would it be possible for you to take a closer look at the execution with a debugger to see exactly where the SIGSEGV occurs?

Member

joesavage commented Jan 12, 2017

Sorry to hear you're having problems, but thanks for reporting them.

With your first issue, it looks like the compiler is assuming an older C standard for some reason — you're quite right that a std flag should be able to resolve this, though we probably want to use C99 in this case and must be careful that this flag doesn't propagate into the list of C++ flags. The second issue you're experiencing is then related to the first, as using asm within C code is a GNU extension that cannot be used with -std={c99, c11}. We could use __asm__ to fix this as you suggested, but for the time being I'll update the CMakeLists.txt file to use -std=gnu99 instead, resolving both of these issues.

As for your last problem, I'm afraid I have no idea what might be causing this. Would it be possible for you to take a closer look at the execution with a debugger to see exactly where the SIGSEGV occurs?

@ziza69

This comment has been minimized.

Show comment
Hide comment
@ziza69

ziza69 Jan 13, 2017

About "simd" functions: Well, it seem to be floating point mismatch. Actually, I was not able to build Demo app for Android because "libNE10.a uses VFP register arguments, output does not". So I have inserted in Android Demo app's "CMakeList.txt" line

"set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wl,--no-warn-mismatch")"

so it builds, but obviously with bad argument length.
Now, I tried with

set(CMAKE_C_FLAGS "-mthumb-interwork -mthumb -march=armv7-a -mfloat-abi=hard -mfpu=vfp3 -Wl,--no-warn-mismatch")

this seems to work.
Note that this is added in "CMakeList.txt" for Android project, this is needed in order for Android app to be compatible with library.
I noted also that there is some tests disabled by default for neon, to enable them I have added

add_definitions(-DENABLE_NE10_FIR_FLOAT_NEON -DENABLE_NE10_FIR_DECIMATE_FLOAT_NEON -DENABLE_NE10_FIR_INTERPOLATE_FLOAT_NEON -DENABLE_NE10_FIR_LATTICE_FLOAT_NEON -DENABLE_NE10_FIR_SPARSE_FLOAT_NEON -DENABLE_NE10_IIR_LATTICE_FLOAT_NEON)

ziza69 commented Jan 13, 2017

About "simd" functions: Well, it seem to be floating point mismatch. Actually, I was not able to build Demo app for Android because "libNE10.a uses VFP register arguments, output does not". So I have inserted in Android Demo app's "CMakeList.txt" line

"set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wl,--no-warn-mismatch")"

so it builds, but obviously with bad argument length.
Now, I tried with

set(CMAKE_C_FLAGS "-mthumb-interwork -mthumb -march=armv7-a -mfloat-abi=hard -mfpu=vfp3 -Wl,--no-warn-mismatch")

this seems to work.
Note that this is added in "CMakeList.txt" for Android project, this is needed in order for Android app to be compatible with library.
I noted also that there is some tests disabled by default for neon, to enable them I have added

add_definitions(-DENABLE_NE10_FIR_FLOAT_NEON -DENABLE_NE10_FIR_DECIMATE_FLOAT_NEON -DENABLE_NE10_FIR_INTERPOLATE_FLOAT_NEON -DENABLE_NE10_FIR_LATTICE_FLOAT_NEON -DENABLE_NE10_FIR_SPARSE_FLOAT_NEON -DENABLE_NE10_IIR_LATTICE_FLOAT_NEON)

@joesavage

This comment has been minimized.

Show comment
Hide comment
@joesavage

joesavage Jan 16, 2017

Member

Great to hear that you've got everything working. So, to be clear, the issue here is that the Android demo project is by default using the soft floating point ABI (softfloat/softfp) internally, while Ne10 is using hardfp? (And thus, to resolve this, the Android project can be compiled to use hardfp internally except from the library calls explicitly marked as soft float with __attribute__((pcs("aapcs"))) [rather than aapcs-vfp for the VFP variant], hence the --no-warn-mismatch.)

It looks like the additional flags you passed to the demo project are already present in Ne10's root CMakeLists.txt file, but if I'm understanding you correctly you resolved this issue by adding these same arguments to Ne10/android/NE10Demo/jni/CMakeLists.txt? I guess the original intention might have been that these flags specified in the root CMakeLists.txt somehow trickle down to the Android demo project, but I'm not quite sure how that would work.

As for the extra tests, these can be enabled more easily by passing -DNE10_ENABLE_DSP=ON (and similarly for NE10_ENABLE_PHYSICS and NE10_ENABLE_IMGPROC), but it looks to me like that flag is enabled by default so I'm surprised that these tests would be disabled for you.

EDIT: It looks like the Android demo's CMakeLists.txt file doesn't include FunctionSwitch.cmake or set NE10_ENABLE_DSP by default, and hence the additional tests don't get enabled. Like the ABI issue, this could be resolved by adding the relevant functionality to Ne10/android/**/CMakeLists.txt (as suggested above).

Member

joesavage commented Jan 16, 2017

Great to hear that you've got everything working. So, to be clear, the issue here is that the Android demo project is by default using the soft floating point ABI (softfloat/softfp) internally, while Ne10 is using hardfp? (And thus, to resolve this, the Android project can be compiled to use hardfp internally except from the library calls explicitly marked as soft float with __attribute__((pcs("aapcs"))) [rather than aapcs-vfp for the VFP variant], hence the --no-warn-mismatch.)

It looks like the additional flags you passed to the demo project are already present in Ne10's root CMakeLists.txt file, but if I'm understanding you correctly you resolved this issue by adding these same arguments to Ne10/android/NE10Demo/jni/CMakeLists.txt? I guess the original intention might have been that these flags specified in the root CMakeLists.txt somehow trickle down to the Android demo project, but I'm not quite sure how that would work.

As for the extra tests, these can be enabled more easily by passing -DNE10_ENABLE_DSP=ON (and similarly for NE10_ENABLE_PHYSICS and NE10_ENABLE_IMGPROC), but it looks to me like that flag is enabled by default so I'm surprised that these tests would be disabled for you.

EDIT: It looks like the Android demo's CMakeLists.txt file doesn't include FunctionSwitch.cmake or set NE10_ENABLE_DSP by default, and hence the additional tests don't get enabled. Like the ABI issue, this could be resolved by adding the relevant functionality to Ne10/android/**/CMakeLists.txt (as suggested above).

@ziza69

This comment has been minimized.

Show comment
Hide comment
@ziza69

ziza69 Jan 16, 2017

Yes, you got it right. I guess easiest way would be to just add those flags manually to Android demo project since it is broken in current state.

ziza69 commented Jan 16, 2017

Yes, you got it right. I guess easiest way would be to just add those flags manually to Android demo project since it is broken in current state.

@joesavage

This comment has been minimized.

Show comment
Hide comment
@joesavage

joesavage Jan 16, 2017

Member

Taking a closer look at this, it seems that the CMakeLists.txt file in Ne10/android/NE10Demo/jni actually gets invoked automatically, carrying across the desired flags, when building from the root directory and specifying the android_config.cmake toolchain file (i.e. compiling Ne10 for Android). Presumably this doesn't automatically build the actual Android application, but it does seem to build the tests. Would you be able to describe your build process for me so we can try to figure out whether it's the problem here?

Member

joesavage commented Jan 16, 2017

Taking a closer look at this, it seems that the CMakeLists.txt file in Ne10/android/NE10Demo/jni actually gets invoked automatically, carrying across the desired flags, when building from the root directory and specifying the android_config.cmake toolchain file (i.e. compiling Ne10 for Android). Presumably this doesn't automatically build the actual Android application, but it does seem to build the tests. Would you be able to describe your build process for me so we can try to figure out whether it's the problem here?

@ziza69

This comment has been minimized.

Show comment
Hide comment
@ziza69

ziza69 Jan 16, 2017

Yes it does but I wanted to play with it and actually copied project in Android studio and well, yes you are correct it does build tests but I did it wrong way :)

ziza69 commented Jan 16, 2017

Yes it does but I wanted to play with it and actually copied project in Android studio and well, yes you are correct it does build tests but I did it wrong way :)

@joesavage

This comment has been minimized.

Show comment
Hide comment
@joesavage

joesavage Jan 16, 2017

Member

Ah, I see! In which case, it seems like everything is resolved.

Member

joesavage commented Jan 16, 2017

Ah, I see! In which case, it seems like everything is resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment