Dbus EXTRA_OECONF

["Steffen Olsen" <steffen.olsen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2115 bytes --]

Hi,

We are currently in the process of examining a memory leak in systemd, which has led us to investigate how dbus is built for our targets (we are currently using Kirkstone).

When kirkstone was introduced, there was made a couple of changes in how dbus is built (oe-core cfecef ( https://git.openembedded.org/openembedded-core/commit/meta/recipes-core/dbus?h=kirkstone&id=cfecef4e6925865961858d0fe5ffc7794c71cd3b ) ). It seems like the dbus-test and dbus recipes were merged, which ultimately changed how (normal) dbus is built. Especially interesting is the changes on EXTRA_OECONF where the following flags are enabled for the "ordinary" dbus recipe

* --enable-tests
* --enable-checks
* --enable-asserts

In dunfell, it seems dbus is built using '--disable-tests'

As far as I can understand, these flags are now enabled for "production build of dbus". We definitely see a link between the mentioned systemd memory leak and the introduction of these flags (especially the '--enable-tests'). Our question is really about whether these flags should be enabled when bitbaking production dbus? When building dbus with the current recipe we do get the following result in the dbus log.do_configure log file

> 
> NOTE: building with unit tests increases the size of the installed library
> and renders it insecure

> 
> NOTE: building with assertions increases library size and decreases
> performance.

Further, from official dbus maintainers we have the following in the NEWS ( https://gitlab.freedesktop.org/dbus/dbus/-/blob/16232bdd339cb8bf4ef9e7d51ce1bcafa574155a/NEWS#L39 ) describing that production builds should be compiled with checks but without assertions. To have some comparison we have tried looking into what other distros do when building dbus, and as far as we can see, at least debian does not set these flags (some are set in dbg packages).

Obviously, we can make a bbappend or something similar to cater for our needs, but we are wondering if this recipe is correct as it stands at the moment. We would appreciate any input on the matter.

br

Jomar and Steffen

[-- Attachment #2: Type: text/html, Size: 3659 bytes --]