Re: [PATCH 12/12] meson: link ARM and RISC-V into qemu-system

I took some ideas from you and improved it to be smaller. I'll send a v2
patches I think it's better, your review concerns are all addressed.

On Thu, Aug 27, 2026 at 2:05 AM Philippe Mathieu-Daudé <
[email protected]> wrote:
>
> On 26/8/26 19:40, Pierrick Bouvier wrote:
> > On 8/26/2026 6:00 AM, Daniel P. Berrangé wrote:
> >> On Mon, Aug 24, 2026 at 09:20:38AM -0700, Pierrick Bouvier wrote:
> >>> On 8/23/2026 8:07 AM, Yonggang Luo wrote:
> >>>> - Build qemu-system (and qemu-systemw on Windows) from aarch64
> >>>>    common/system objects plus RISC-V arch objects taken from the
> >>>>    existing riscv64 lib.
> >>>> - Pull 32-bit TargetInfo and 32-only boards from the arm/riscv32
> >>>>    libs so hw/arm and target/riscv are not compiled twice.
> >>>> - Skip linking qemu-system-{arm,aarch64,riscv32,riscv64} and the
> >>>>    Windows *w variants; symlink those names to qemu-system so
> >>>>    argv[0] still selects TargetInfo.
> >>>>
> >>>> Signed-off-by: Yonggang Luo <[email protected]>
> >>>> ---
> >>>>   meson.build | 156
+++++++++++++++++++++++++++++++++++++++++++++++++---
> >>>>   1 file changed, 147 insertions(+), 9 deletions(-)
> >>
> >> I think this approach of taking common/system from aarch64
> >> and adding in riscv specific objects only works by luck.
> >>
> >> That's not obvious from your patch, but Pierrick's counterproposal
> >> below will expose it with a little  tweak....
> >>
> >>
> >>>  From 6261b0c255e1a8f0df2b41928b8dfb365d0fa488 Mon Sep 17 00:00:00
2001
> >>> From: Pierrick Bouvier <[email protected]>
> >>> Date: Tue, 14 Apr 2026 10:56:15 -0700
> >>> Subject: [PATCH] meson: build single binary
> >>>
> >>> This is not built by default.
> >>> Build with: ninja -C build qemu-system
> >>>
> >>> All available *-softmmu targets are aggregated, ./configure
> >>> --target-list can be used to restrict which targets are included.
> >>>
> >>> In case user has targets that are not supported, we emit an error
> >>> message when build qemu-system target. This way, it's not necessary to
> >>> have a custom configure flag, and qemu-system can live next to
existing
> >>> binaries without complexifying the workflow more than it is already.
> >>>
> >>> Signed-off-by: Pierrick Bouvier <[email protected]>
> >>> ---
> >>>   meson.build | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
> >>>   1 file changed, 48 insertions(+)
> >>>
> >>> diff --git a/meson.build b/meson.build
> >>> index 553df3e7f053..4a31a520d9eb 100644
> >>> --- a/meson.build
> >>> +++ b/meson.build
> >>> @@ -4264,6 +4264,9 @@ if host_os == 'darwin'
> >>>   endif
> >>>
> >>>   traceable = []
> >>> +single_binary_libs = []
> >>> +single_binary_deps = []
> >>> +single_binary_crates = []
> >>>   emulators = {}
> >>>   foreach target : target_dirs
> >>>     config_target = config_target_mak[target]
> >>> @@ -4419,6 +4422,10 @@ foreach target : target_dirs
> >>>                    build_by_default: false)
> >>>
> >>>     if target.endswith('-softmmu')
> >>> +    single_binary_libs += lib
> >>> +    single_binary_deps += arch_deps
> >>> +    single_binary_deps += target_stubs
> >>> +    single_binary_crates += main_rs
> >>>       execs = [{
> >>>         'name': 'qemu-system-' + target_name,
> >>>         'win_subsystem': 'console',
> >>> @@ -4500,6 +4507,47 @@ foreach target : target_dirs
> >>>     endforeach
> >>>   endforeach
> >>>
> >>> +single_binary_objects = []
> >>> +foreach lib: single_binary_libs
> >>> +  single_binary_objects += lib.extract_all_objects(recursive: true)
> >>> +endforeach
> >>> +
> >>> +single_binary_link_args = emulator_link_args
> >>> +single_binary_link_args += enable_modules ? ['@block.syms',
'@qemu.syms'] : []
> >>> +
> >>> +supported_targets = [
> >>> +  'aarch64-softmmu',
> >>> +  'arm-softmmu',
> >>> +]
> >>
> >> Adding in riscv64-softmmu to this list and building with
> >> configure --target-list=aarch64-softmmu,riscv64-softmmu
> >> will fail with this meson approach.
> >>
> >
> > Maybe it's now more obvious why our original goal, presented at KVM
> > Forum 2025, was to have only arm/aarch64/microblaze, and not riscv.
> > It just requires more work to have it, and iteration is key. But we need
> > a minimum viable product to start somewhere.
> >
> > It is still our goal to this date.
> >
> >> Specifically we'll hit duplicate symbols to to taking
> >> different KConfig branches, resulting in building in
> >> both the real impl and the stubs:
> >>
> >>    /usr/bin/ld.bfd:
libsystem.a.p/hw_pci-bridge_pci_expander_bridge_stubs.c.o: in function
`pxb_cxl_hook_up_registers':
> >>
/home/berrange/src/virt/qemu/build-alt/../hw/pci-bridge/pci_expander_bridge_stubs.c:14:
multiple definition of `pxb_cxl_hook_up_registers';
libsystem.a.p/hw_pci-bridge_pci_expander_bridge.c.o:/home/berrange/src/virt/qemu/build-alt/../hw/pci-bridge/pci_expander_bridge.c:214:
first defined here
> >>
> >
> > There is nothing new here, and we discovered all that more than a year
> > ago. That's why we started using stub_ss more, as it provides the weak
> > symbol semantic we need. It's not the end of the story though, as we'll
> > have to adapt some functions to this new "multi target" world.
> > But to be able to test and debug that, we need to have a single-binary
> > first.
>
> I will try to find time to finish that 'HOWTO convert to single-binary'
> document I proposed to Daniel Barboza and Anton Johansson which is
> structured as "why / how / commit references", that could help Yonggang
> and others to understand why this effort is taking so long.



--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo