On Fri, 11 Nov 2022 10:43:30 +0100
Igor Mammedov <imamm...@redhat.com> wrote:
> On Thu, 10 Nov 2022 09:28:44 +0000
> Peter Maydell <peter.mayd...@linaro.org> wrote:
>
> > On Wed, 9 Nov 2022 at 21:42, Michael S. Tsirkin <m...@redhat.com> wrote:
> >
> > > > > diff --git a/hw/display/meson.build b/hw/display/meson.build
> > > > > index adc53dd8b6..7a725ed80e 100644
> > > > > --- a/hw/display/meson.build
> > > > > +++ b/hw/display/meson.build
> > > > > @@ -38,10 +38,21 @@ softmmu_ss.add(when: 'CONFIG_NEXTCUBE', if_true:
> > > > > files('next-fb.c'))
> > > > > specific_ss.add(when: 'CONFIG_VGA', if_true: files('vga.c'))
> > > > > +if (config_all_devices.has_key('CONFIG_VGA_CIRRUS') or
> > > > > + config_all_devices.has_key('CONFIG_VGA_PCI') or
> > > > > + config_all_devices.has_key('CONFIG_VMWARE_VGA') or
> > > > > + config_all_devices.has_key('CONFIG_ATI_VGA')
> > > > > + )
> > > > > + softmmu_ss.add(when: 'CONFIG_ACPI', if_true: files('acpi-vga.c'),
> > > > > + if_false:
> > > > > files('acpi-vga-stub.c'))
> > > > > +endif
> > >
> > > Igor what does CONFIG_ACPI mean? It depends on the target but this
> > > library is target independent. Is this just always built then?
> >
> > That kind of config symbol means "some machine we want to build needs
> > ACPI, so build it". So if you build at least one machine that needs
> > ACPI, CONFIG_ACPI gets defined, and the acpi-specific files are built.
> > If your QEMU configure line and possibly any custom config file
> > mean you're not building any ACPI machines, then CONFIG_ACPI is
> > not defined, and we don't need to build in the acpi-specifics,
> > which makes the binary smaller. For instance if you set
> > --target-list=or1k-softmmu then no machine wants ACPI and
> > CONFIG_ACPI won't get set. If you set
> > --target-list=or1k-softmmu,x86_64-softmmu
> > then the PC machine types want ACPI and CONFIG_ACPI is set.
> >
> > (Essentially we're opting to make the build faster by building the
> > object file once rather than per-target, at the cost of the
> > executables for the target architectures which don't use the
> > feature being a bit bigger with code they aren't going to use.)
> >
> > Note that this means that for a machine type which does not use ACPI, it
> > may either:
> > (1) be being built in the same build as a machine that does use
> > ACPI, so be linked against the "real" ACPI source files
> > (2) be being built in a build with no ACPI machines, so be
> > linked against the stub files
> >
> > and it also means that the code in the "real" ACPI source files
> > cannot assume that it's being used in a machine which is actually
> > using ACPI.
>
[...]
> Even if it were not the case linking 'real' code in this case
> shouldn't have caused issues on machine that do not actually
> invoke it.
Well, aarch64 target is this case wher it has a mix of ACPI and
non-ACPI machines. As mentinod aove this shouldn't be the issue
in this case.
But are there ideas how to deal with such cases cleanly
(modulo tweaking 'real' code to deal with both cases)?
[...]
>
> > thanks
> > -- PMM
> >
>
