[Buildroot] BR2_ENABLE_DEBUG is (incorrectly) using `Debug` for CMAKE_BUILD_TYPE instead of `RelWithDebInfo`
joker.eph at gmail.com
Wed Aug 23 09:45:15 UTC 2017
I've been bitten by what I think is a surprising behavior of :
Here is the documentation for BR2_ENABLE_DEBUG:
bool "build packages with debugging symbols"
Build packages with debugging symbols enabled. All libraries
and binaries in the 'staging' directory will have debugging
symbols, which allows remote debugging even if libraries and
binaries are stripped on the target. Whether libraries and
binaries are stripped on the target is controlled by the
BR2_STRIP_* options below.
The option is supposed to enable debug symbols emission by the compiler.
The description mentions that the purpose is to enable remote debugging
using `staging` even after stripping the binaries in `target`.
However, by using `Debug` as `CMAKE_BUILD_TYPE` the option is not
orthogonal to other settings and have side-effects. In CMake, the
CMAKE_BUILD_TYPE is not *only* controlling the debug info emission but also
the optimization level for instance. Also, and with even more concerns,
packages may use this to trigger other settings.
It seems it has swing'd multiple times last year, first going from `Debug`
to `RelWithDebInfo` here:
http://lists.busybox.net/pipermail/buildroot/2016-June/163639.html and here
http://lists.busybox.net/pipermail/buildroot/2016-July/165714.html ; and
then back to `Debug` here:
(haven't found the mailing list discussion)
The latter claims that switching from `Release` to `Debug` is "semantically
closer" to the intent of the option in buildroot. If that is the case, the
doc does not seem to reflect correctly this intent to me: I always want to
build a "release" package, only to have debug-info emitted in my staging
All the other settings mentioned in this commit message (assertions
enabled/disabled, optimization level, etc.) can be (and actually are I
think) handled orthogonally using other CMake flags.
Using the same CMAKE_BUILD_TYPE as a base and overriding individual setting
seems like a more sane and robust approach to me.
Two practical examples of packages that shows what can go wrong:
1) ceres-solver ( https://github.com/ceres-solver/ceres-solver )
When configured with CMAKE_BUILD_TYPE=Release, it'll generate:
However with CMAKE_BUILD_TYPE=Debug we end up with:
2) the LLVM compiler is doing special casing based on the value of
CMAKE_BUILD_TYPE. For example:
if (NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" AND
NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "RELWITHDEBINFO")
# Use -O1 even in debug mode, otherwise sanitizers slowdown is too
if (uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG")
if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
option(LLVM_ENABLE_ASSERTIONS "Enable assertions" OFF)
option(LLVM_ENABLE_ASSERTIONS "Enable assertions" ON)
In my experience it has been quite common for CMake projects to use
CMAKE_BUILD_TYPE to differentiate on more than just default optimization
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the buildroot