On Tue, 15 Nov 2011 at 19:02:48 +0000, Neil Williams wrote:
> Fix the rest of the flags. In most cases, what you're thinking of as
> the "release" build may actually contain debug symbols which dh_strip
> would then put into a dbg package. What matters (the only thing
> which matters) is exactly what is passed to g++.
Some packages/build systems do distinguish between a "debug" and "release"
build, and actually compile different code for the two (e.g. python2.7-dbg
has a lot of reference-count-debugging goo which just doesn't exist in
python2.7), or do things like changing the level of optimization.
I believe this is particularly popular in things originating on Windows
(iirc MSVC++ has release- and debug-mode runtime libraries, which are not
the same).
For instance, the "release" version might build with -NDEBUG
(disable assert(3)), -DG_DISABLE_ASSERTS (the equivalent for GLib), or even
-DG_DISABLE_CHECKS (the "break my app" flag). In some packages (like Python),
the debug version even has a different ABI (again, for the intrusive
reference-count-debugging stuff, which makes all your objects a bit larger).
I personally think this sort of thing should be avoided wherever possible -
not least because you run the risk of having bugs that can be reproduced
with the release version but not the debug version - but it's something that
happens, unfortunately including packages I maintain.
In Debian, we build everything with debug symbols (-g), but usually using the
code paths that would normally be considered a "release" version.
CMake formalizes this by having "Debug", "Release" and "RelWithDebInfo"
values for CMAKE_BUILD_TYPE: the one normally used in Debian is
RelWithDebInfo.
S
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20111115192610.gb29...@reptile.pseudorandom.co.uk
