The macro block_module_load() used by block.c is a wrapper around
module_load(), which is implemented in util/module.c.

Fixes linking for a future binary or downstream binary that does not
depend on 'qemuutil' directly, but does depend on 'block'.

Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 81ecd4bae7..efa0ac8d0b 100644
--- a/meson.build
+++ b/meson.build
@@ -3555,7 +3555,7 @@ if have_block
     'blockjob.c',
     'job.c',
     'qemu-io-cmds.c',
-  ))
+  ), qemuutil)
   if config_host_data.get('CONFIG_REPLICATION')
     block_ss.add(files('replication.c'))
   endif
-- 
2.39.2

On Wed, Aug 14, 2024 at 12:00:52PM +0200, Fiona Ebner wrote:
> The macro block_module_load() used by block.c is a wrapper around
> module_load(), which is implemented in util/module.c.
> 
> Fixes linking for a future binary or downstream binary that does not
> depend on 'qemuutil' directly, but does depend on 'block'.

Such a scenario is impossible surely, even in future. Every file in
QEMU pulls in osdep.h, and as a result effectively gets a dep on
on qemuutil, not to mention the block layer using countless APIs
present in qemuutil

> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index 81ecd4bae7..efa0ac8d0b 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -3555,7 +3555,7 @@ if have_block
>      'blockjob.c',
>      'job.c',
>      'qemu-io-cmds.c',
> -  ))
> +  ), qemuutil)
>    if config_host_data.get('CONFIG_REPLICATION')
>      block_ss.add(files('replication.c'))
>    endif
> -- 
> 2.39.2
> 
> 

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Am 15.08.24 um 17:58 schrieb Daniel P. Berrangé:
> On Wed, Aug 14, 2024 at 12:00:52PM +0200, Fiona Ebner wrote:
>> The macro block_module_load() used by block.c is a wrapper around
>> module_load(), which is implemented in util/module.c.
>>
>> Fixes linking for a future binary or downstream binary that does not
>> depend on 'qemuutil' directly, but does depend on 'block'.
> 
> Such a scenario is impossible surely, even in future. Every file in
> QEMU pulls in osdep.h, and as a result effectively gets a dep on
> on qemuutil, not to mention the block layer using countless APIs
> present in qemuutil
> 

Yes, you are right. Sorry, I missed this dependency. The sources for
both of our affected downstream binaries do include "qemu/osdep.h" and
thus have a direct dependency on qemuutil. So my patch can be disregarded.

Build for the mentioned binaries broke after, IIRC, 414b180d42 ("meson:
Pass objects and dependencies to declare_dependency()"), because they
didn't explicitly specify the qemuutil dependency in meson. The error
message I got was about "module_load" used by the block layer.

Best Regards,
Fiona

On 14/08/2024 12.00, Fiona Ebner wrote:
> The macro block_module_load() used by block.c is a wrapper around
> module_load(), which is implemented in util/module.c.
> 
> Fixes linking for a future binary or downstream binary that does not
> depend on 'qemuutil' directly, but does depend on 'block'.
> 
> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
> ---
>   meson.build | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index 81ecd4bae7..efa0ac8d0b 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -3555,7 +3555,7 @@ if have_block
>       'blockjob.c',
>       'job.c',
>       'qemu-io-cmds.c',
> -  ))
> +  ), qemuutil)
>     if config_host_data.get('CONFIG_REPLICATION')
>       block_ss.add(files('replication.c'))
>     endif

Reviewed-by: Thomas Huth <thuth@redhat.com>

... and CC:-ing the block maintainers, hoping that they can have a look, 
too, and finally pick up this patch.