On Tue, Aug 06, 2019 at 03:07:40PM +0200, Paolo Bonzini wrote:
> On 06/08/19 11:41, Daniel P. Berrangé wrote:
> > On Tue, Aug 06, 2019 at 09:11:15AM +0200, Paolo Bonzini wrote:
> >> qcrypto_random_*, AES and qcrypto_init do not need to be linked as a whole
> >> and are the only parts that are used by user-mode emulation. Place them
> >> in libqemuutil, so that whatever needs them will pick them up
> >> automatically.
> >>
> >> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
> >> ---
> >> MAINTAINERS | 3 +++
> >> Makefile | 4 +---
> >> Makefile.objs | 1 -
> >> Makefile.target | 2 --
> >> crypto/Makefile.objs | 7 -------
> >> util/Makefile.objs | 5 +++++
> >> {crypto => util}/aes.c | 0
> >> crypto/init.c => util/crypto-init.c | 0
> >> {crypto => util}/random-gcrypt.c | 0
> >> {crypto => util}/random-gnutls.c | 0
> >> {crypto => util}/random-platform.c | 0
> >
> > Ewww, definitely do not want to see these files moved as it spreads the
> > crypto related code over multiple locations again, which is exactly what
> > I spent time fixing when introducing the crypto/ directory.
> >
> > Placing them to libqemuutil.a shouldn't mean we need to move the code too.
>
> Fair enough, will do in v2.
I would love to be able to have a libqemucrypto.a library for everything
in crypto/ really, but the way we do QOM registration via library
constructors breaks this. The ld linker isn't clever enough to see the .o
is used via a constructor so unhelpfully throws away all the .o files
containing QOM objects :-(
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
