| Message ID | 20240814100052.263060-1-f.ebner@proxmox.com |
|---|---|
| State | New |
| Headers | show |
| Series | meson: add 'qemuutil' dependency for block.c | expand |
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.
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
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
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
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(-)