* Dbus EXTRA_OECONF
@ 2024-02-20 12:35 Steffen Olsen
2024-02-20 13:14 ` [OE-core] " Alexander Kanavin
[not found] ` <17B59473B9744748.436@lists.openembedded.org>
0 siblings, 2 replies; 3+ messages in thread
From: Steffen Olsen @ 2024-02-20 12:35 UTC (permalink / raw)
To: openembedded-core
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [OE-core] Dbus EXTRA_OECONF
2024-02-20 12:35 Dbus EXTRA_OECONF Steffen Olsen
@ 2024-02-20 13:14 ` Alexander Kanavin
[not found] ` <17B59473B9744748.436@lists.openembedded.org>
1 sibling, 0 replies; 3+ messages in thread
From: Alexander Kanavin @ 2024-02-20 13:14 UTC (permalink / raw)
To: Steffen Olsen; +Cc: openembedded-core
On Tue, 20 Feb 2024 at 13:35, Steffen Olsen <steffen.olsen@gmail.com> wrote:
> 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). 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 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.
Thanks for spotting these. I took a look at the source code to see
what conditions trigger those two notes:
if test x$enable_embedded_tests = xyes; then
echo "NOTE: building with unit tests increases the size of the
installed library and renders it insecure."
fi
if test x$enable_asserts = xyes; then
echo "NOTE: building with assertions increases library size
and decreases performance."
fi
As far as I understand it's only those embedded tests that are
problematic, and other kinds of tests (e.g. modular tests) don't
affect how the library is built. So perhaps you can make a patch that
passes in (or removes) the respective autoconf options, so that the
above conditions no longer are true?
Alex
^ permalink raw reply [flat|nested] 3+ messages in thread[parent not found: <17B59473B9744748.436@lists.openembedded.org>]
* Re: [OE-core] Dbus EXTRA_OECONF
[not found] ` <17B59473B9744748.436@lists.openembedded.org>
@ 2024-02-20 19:59 ` Alexander Kanavin
0 siblings, 0 replies; 3+ messages in thread
From: Alexander Kanavin @ 2024-02-20 19:59 UTC (permalink / raw)
To: alex.kanavin; +Cc: Steffen Olsen, openembedded-core
On Tue, 20 Feb 2024 at 14:14, Alexander Kanavin via
lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org>
wrote:
> As far as I understand it's only those embedded tests that are
> problematic, and other kinds of tests (e.g. modular tests) don't
> affect how the library is built. So perhaps you can make a patch that
> passes in (or removes) the respective autoconf options, so that the
> above conditions no longer are true?
I have now sent this patch.
Alex
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-02-20 19:59 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-02-20 12:35 Dbus EXTRA_OECONF Steffen Olsen
2024-02-20 13:14 ` [OE-core] " Alexander Kanavin
[not found] ` <17B59473B9744748.436@lists.openembedded.org>
2024-02-20 19:59 ` Alexander Kanavin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox