Skip to content
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

Debug flag is enabled for release build type. #243

Open
piwinux opened this issue Nov 24, 2016 · 16 comments
Open

Debug flag is enabled for release build type. #243

piwinux opened this issue Nov 24, 2016 · 16 comments
Milestone

Comments

@piwinux
Copy link

piwinux commented Nov 24, 2016

Description

The toolchain file provided for CMake (found in build/cmake/android.toolchain.cmake) enables the debug flags -g in Release mode.

Excerpt of the toolchain file:

# Generic flags.
list(APPEND ANDROID_COMPILER_FLAGS
        -g
       ...)
# ...
# Debug and release flags.
list(APPEND ANDROID_COMPILER_FLAGS_DEBUG
        -O0)

It seems that the -g should be set for ANDROID_COMPILER_FLAGS_DEBUG, not ANDROID_COMPILER_FLAGS.

A workaround is to set CMAKE_CXX_FLAGS_RELEASE to -g0 when configuring the build directory.

Environment Details

Not all of these will be relevant to every bug, but please provide as much
information as you can.

  • NDK Version: Pkg.Revision = 13.0.3315539
  • Build sytem: CMake
  • Host OS: Linux Debian Jessie
  • Compiler: Clang
  • ABI: arm64-v8a
@DanAlbert
Copy link
Member

I'm guessing this was done for the same reason we do this in ndk-build: we always build a debugable binary but strip the debug info for the APK. I've sent an email to the Studio folks to find out if this is something that we can just fix, or if that's going to break Studio's debugging features (I don't know if they actually use Debug/Release modes).

@DanAlbert
Copy link
Member

Yeah, sounds like Studio is expecting this. If you're using cmake via gradle, gradle will strip the debug info when you package the app. If you're not using gradle, you'll need to add that logic to your packaging tools.

@DanAlbert
Copy link
Member

Closed for now, but if there's enough demand for this (I assume the case here is people using cmake and custom packaging tools rather than gradle), it should probably be re-opened and we can look in to getting Studio to do something different.

@piwinux
Copy link
Author

piwinux commented Dec 1, 2016

Thanks for the reply! I understand that Studio is expecting compilation with debug flags even in release mode, but this is counter-intuitive in general, and goes against the default behavior one expects when using CMake in particular. This is actually why I filed this bug.

By default, CMake provides four build types: Debug, MinSizeRel, Release, and RelWithDebInfo. The behavior you describe (a release crafted with debug information) pertains with the RelWithDebInfo build type. I understand the specific needs for Studio, and I definitely understand the need/desires to change the default flags set by CMake, but I believe that the build flags set by the toolchain file should be aligned with the meaning of the build type.

If you're not using gradle, you'll need to add that logic to your packaging tools.

The Gradle behavior (stripping the debug symbols afterward) is a specific case, as is how Studio uses CMake. I fail to understand why I would need to do extra work to address a behavior that should not even happen when compiling a release.

@DanAlbert
Copy link
Member

I've followed up on the email I sent earlier. All makes sense to me, but unfortunately it isn't my decision.

@DanAlbert
Copy link
Member

Alright, looks like Studio is going to start using RelWithDebInfo in a future release (I think it's too late for 2.3 at this point). They've opened a bug for their side of things: https://code.google.com/p/android/issues/detail?id=229391

Reopening this for tracking the toolchain file fix. I think we can't actually change anything until their fix lands or we'll end up breaking their debugging, so this is going in the unplanned bucket for now.

@DanAlbert DanAlbert reopened this Dec 2, 2016
@DanAlbert DanAlbert removed the wontfix label Dec 2, 2016
@DanAlbert DanAlbert added this to the unplanned milestone Dec 2, 2016
@piwinux
Copy link
Author

piwinux commented Dec 5, 2016

Hi, thanks a lot for the feedback. Nice to know it will be considered.

@tallytalwar
Copy link

Perfect.

On our project, we recently moved to native build setup via gradle using externalnativebuild and cmake and noticed bloated native library sizes in our aar's. But the final apk had stripped out minified native library.

In full agreement with the description of the issue here, and appreciate the android studio team considering the request. 👍

tallytalwar added a commit to tangrams/tangram-es that referenced this issue Feb 8, 2017
- to disable `-g` debug flag being set by the ndk default android cmake toolchain
- Refer: android/ndk#243

TODO: Keep an eye for future versions of ndk/android-studio to add a fix for this
tallytalwar added a commit to tangrams/tangram-es that referenced this issue Feb 8, 2017
- to disable `-g` debug flag being set by the ndk default android cmake toolchain
- Refer: android/ndk#243

TODO: Keep an eye for future versions of ndk/android-studio to add a fix for this
tallytalwar added a commit to tangrams/tangram-es that referenced this issue Feb 8, 2017
- to disable `-g` debug flag being set by the ndk default android cmake toolchain
- Refer: android/ndk#243

TODO: Keep an eye for future versions of ndk/android-studio to add a fix for this
meyerj added a commit to Intermodalics/ros_android that referenced this issue Dec 4, 2018
This dramatically reduces the size of the archives and binaries.
For some reason the android.toolchain.cmake file provided by Android NDK adds
-g to the compiler flags, even when building in Release mode (the default).

A new build mode RelWithDebInfo has been added to the patched android.toolchain.cmake
file, which matches the standard behavior of the Android NDK.

There is an open issue at android/ndk#243 that describes
the rationale.
@sizeak
Copy link

sizeak commented Nov 20, 2019

I am amazed that this is still an open issue 3 years later. Can we get this fixed please, it doesn't sound very difficult if Android Studio is now using RelWithDebInfo... although reading the linked issue it appears that it is not yet, sorry.

@enh-google
Copy link
Collaborator

no, the problem is that Studio currently requires this. that's bug https://code.google.com/p/android/issues/detail?id=229391 and until/unless that's fixed, there's nothing we can do in the NDK.

@baryluk
Copy link

baryluk commented Oct 5, 2020

This is not a bug IMHO, and working as intended, so should be closed. Release version has nothing to do whatever debug symbols are present or not. If you really want to change this behavior just set CMAKE_CXX_FLAGS_RELEASE manually.

@vvb2060
Copy link

vvb2060 commented Mar 27, 2021

Turn off some optimizations:

  1. Release: -O3 -DNDEBUG
  2. Debug: -O0 -g
  3. RelWithDebInfo: -O2 -g -DNDEBUG
  4. MinSizeRel: -Os -DNDEBUG

Breaking expected behavior, we think it's Release, but it's not:

if (CMAKE_BUILD_TYPE STREQUAL "Release")
    set(C_FLAGS "${C_FLAGS} -Os -fvisibility=hidden -fvisibility-inlines-hidden")
    set(LINKER_FLAGS "${LINKER_FLAGS} -Wl,-exclude-libs,ALL -Wl,--gc-sections -Wl,--strip-all")
else ()
    set(C_FLAGS "${C_FLAGS} -O0")
endif ()

@DanAlbert
Copy link
Member

Looks like https://issuetracker.google.com/37128614 was fixed so now we need to wait for that version of AGP to release and decide on a compatibility window (whatever NDK we change this in will be incompatible with all current AGP versions).

@vvb2060
Copy link

vvb2060 commented Mar 29, 2021

I expect when AGP does a release build, cmake does a release build, when AGP does a debug build, cmake does a debug build and the so files in the apk include debug symbols to get a clear crash report at runtime.
I think this should be the default behavior, it is intuitive.

@ericoporto

This comment was marked as off-topic.

@DanAlbert

This comment was marked as off-topic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants