Re: [Qemu-devel] [RFC PATCH 00/11] Stubs cleanup

[Paolo Bonzini <pbonzini@redhat.com>]

----- Original Message -----
> From: "Markus Armbruster" <armbru@redhat.com>
> To: "Paolo Bonzini" <pbonzini@redhat.com>
> Cc: "Eduardo Habkost" <ehabkost@redhat.com>, "Peter Maydell" <peter.maydell@linaro.org>, "Fam Zheng"
> <famz@redhat.com>, "QEMU Developers" <qemu-devel@nongnu.org>
> Sent: Friday, December 23, 2016 10:02:33 AM
> Subject: Re: [Qemu-devel] [RFC PATCH 00/11] Stubs cleanup
> 
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
> > On 22/12/2016 18:42, Eduardo Habkost wrote:
> >> On Thu, Dec 22, 2016 at 06:32:24PM +0100, Paolo Bonzini wrote:
> >>>
> >>>
> >>> On 22/12/2016 18:30, Peter Maydell wrote:
> >>>> On 22 December 2016 at 15:59, Paolo Bonzini <pbonzini@redhat.com> wrote:
> >>>>> This moves out of libqemustub.a those functions which can be handled
> >>>>> simply by $(call lnot), like we already do for pci-stub.c or
> >>>>> kvm-stub.c.
> >>>>> libqemustub.a keep the more complex cases where a small part of the
> >>>>> executables we build needs an implementation of a small subset of an
> >>>>> API.
> >>>>
> >>>> So why is doing it this way round better? (I don't have a strong
> >>>> opinion here, but you don't really give a rationale for this change.)
> >>>
> >>> I don't really have a strong opinion here either, hence the RFC.
> >>> However, one advantage is that it keeps things visible to the right
> >>> maintainer.
> >> 
> >> Can't we just move the files to subdirectories where they are
> >> visible to the maintainers, but keep using stub-obj-y/libqemustub
> >> to build/link them?
> >> 
> >> I find libqemustub/stub-obj-y much easier to use than manually
> >> setting obj-$(call lnot ...).
> >
> > Yes, that would work too.  It's a pity that we cannot just use weak
> > symbols, as that would work fine with obj-y.
> 
> Can you explain again why we can't use weak symbols?

Because Windows and OS X don't have full support for weak symbols.
At least as I understand it, OS X only supports "weak import" of
a symbol from a library, where if a symbol is missing _in the library_
it resolves to NULL in the program.  It doesn't support replacing a
weak definition of a function with a strong definition of the same,
and that's why we use a static library.

Paolo