On 3/12/25 15:23, Daniel P. Berrangé wrote:
My question is, is this expected behavior or is this a bug?
Your configure args don't include "--enable-debug", so I would
not have expected -gsplit-dwarf to have been enabled, so I'm
surprised that commit casued a problem.
Hmm it appears that the meson "get_option('debug')" is entirely
unconnected to QEMU's --enable-debug configure flag, which I did
not realize.
Indeed get_option('debug') is connected to --enable-debug-info (which is
default-enabled).
IOW, we've got -gsplit-dwarf enabled by default for everyone
building QEMU, which feels dubious. IMHO only an explicit
--enable-debug configure arg should have triggered it.
I didn't realize that you meant to attach it to --enable-debug. The
reason why meson.build checks get_option('debug') is simply because
-gsplit-dwarf implies turning on debug info.
Maybe it could use something like
diff --git a/configure b/configure
index 5d19d0036a1..18fd82a187e 100755
--- a/configure
+++ b/configure
@@ -1873,6 +1873,10 @@ if test "$skip_meson" = no; then
{ test "$host_os" = linux || test "$host_os" = "windows"; }; then
echo 'werror = true' >> $cross
fi
+ if test -e "$source_path/.git" && test "$host_os" != "windows"; then
+ echo 'split_debug = true' >> $cross
+ fi
+
echo "[project options]" >> $cross
if test "$SMBD" != ''; then
echo "smbd = $(meson_quote "$SMBD")" >> $cross
diff --git a/meson_options.txt b/meson_options.txt
index 809d0b42ef7..751dc39d22f 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -360,7 +360,7 @@ option('debug_mutex', type: 'boolean', value: false,
description: 'mutex debugging support')
option('debug_stack_usage', type: 'boolean', value: false,
description: 'measure coroutine stack usage')
-option('split_debug', type: 'boolean', value: true,
+option('split_debug', type: 'boolean', value: false,
description: 'split debug info from object files')
option('qom_cast_debug', type: 'boolean', value: true,
description: 'cast debugging support')
similar to --enable-werror... by the way I'm not sure if checking
for .git still works - I think recent RPM creates a fake git repo
to be able to run "git am", does it get rid of the .git directory
before starting the build?
In addition since its breaking Windows builds, it appears we
need to block its usage on Windows.
Yes, that's needed.
Paolo
