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

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.