[Pkg-mpd-maintainers] Bug#998310: mpd: fails to start with "Assertion `sockets.empty()' failed."

[Max Kellermann]

On 2021/11/04 19:32, kaliko <kaliko at azylum.org> wrote:
> I had a look at the 0.23.3-1 build and actually debhelper calls meson with
> "--wrap-mode=nodownload --buildtype=plain --prefix=/usr …" plus some *dir
> options [2]. Then indeed asserts are not disabled but it's not really a
> debug build either in meson terminology at least [0].

It's a debug build if debug options are enabled.  There's are two generic
Meson debug options:

- "b_ndebug" (negated: which *disables* debugging features such as
  runtime assertions) - disabled by default, i.e. assertions are
  *enabled*

- "cpp_debugstl" is essentially the same, just for the C++ standard
  library, and it's not negated.  This one is disabled by default,
  i.e. assertions are *disabled*

Note that "--buildtype=debug" does NOT enable a debug build.  The name
is really confusing.  Meson documentation says:

 "debug info is generated but the result is not optimized"

This is about debug info (GCC option "-g"), which is of course needed
to debug a program in gdb, but it's not at all about enabling or
disabling debugging features in the generated code.  Debug info has no
effect on the code or on the performance.

(btw. "--buildtype=release" is very much useless.
"--buildtype=debugoptimized" generates the same code, but doesn't omit
debug info, which can be useful after a crash has occurred.  Without
debug info, crash dumps cannot be analyzed, and debug info cannot ever
be reproduced if it has been omitted in the build.)

> Anyway the way we build the package differs from upstream recommendations
> [1]: " --buildtype=debugoptimized -Db_ndebug=true".
> 
> Correct me if I'm wrong Max, but upstream considers this has an impact on
> runtime performances.

I am MPD upstream, and I do not just "consider" that, but it's an
undisputable fact.  And it is a fact for *all* C or C++ programs which
use assert().  Which is a very common thing.  Not defining NDEBUG has
a considerable effect on executable size, compiler optimizations and
runtime performance.  This overhead is useful when searching for bugs,
but not useful for normal users of an application.

IMHO all Debian packages should build with NDEBUG, so this should
really be a central debhelper feature.

> The question is then, should we add "b_ndebug=true"?
> I did not find any mention of NBDEBUG in policies.

Indeed Debian does not mention this anywhere.  But as I said, it
should be added to the policy (and to debhelper).

Max