Re: [Xen-devel] [libvirt] Likely build race, "/usr/bin/ld: cannot find -lvirt"

[Jiri Denemark <jdenemar@xxxxxxxxxx>]

On Tue, Jun 12, 2018 at 07:57:40 -0500, Eric Blake wrote:
> On 06/12/2018 06:11 AM, Jiri Denemark wrote:
> 
> > I hit the same race twice on aarch64 and ppc64 and I can confirm the
> > installation phase fails if libvirt.la is installed later than libraries
> > which link to it. However, the dependencies seem to be set correctly in
> > the Makefiles. But it looks like they are only honored when linking the
> > library during the build phase. During make install libvirt.la and
> > libraries which link to it are installed independently. That is,
> > install-modLTLIBRARIES does not depend on anything except for the
> > mod_LTIBRARIES themselves. Thus when libtool decides to relink the
> > libraries libvirt.la may still be missing at this point. Manually
> > changing
> > 
> >      install-modLTLIBRARIES: $(mod_LTLIBRARIES)
> > 
> > to
> > 
> >      install-modLTLIBRARIES: $(mod_LTLIBRARIES) install-libLTLIBRARIES
> > 
> > fixed the problem for me (tested with an artificial delay added to
> > install-libLTLIBRARIES target), but I have no idea how to persuade
> > automake to generate something like that for us.
> > 
> > Eric, is my investigation correct and do you have any ideas on how to
> > fix the race?
> 
> Can you add that line directly into Makefile.am, or does doing that 
> cause automake to complain and/or omit its normal rules because it 
> thinks you are overriding its defaults?

Yeah. It doesn't complain, but it omits its normal
install-modLTLIBRARIES rule which mean nothing will be installed.
However, the error is still reported so there are other libraries which
are not in mod_LTLIBRARIES affected too.

I also tried adding install-modLTLIBRARIES-local target, but it didn't
work either since automake doesn't use this target (well I didn't really
hope it would work, but I tried it anyway).

It's not really surprising bisecting found the following commit which
introduced the race, but I'm not really sure how to fix it. Isn't this a
bug in automake? :-)

commit 21639744f6371db0bfa1bd0d21fe5c51c6d6878a
Author: Daniel P. Berrangé <berrange@xxxxxxxxxx>
Date:   Thu Jan 25 09:35:56 2018 +0000

    build: explicitly link all modules with libvirt.so
    
    The dlopened modules we currently build all use various symbols from
    libvirt.so, but don't actually link to it. They rely on the libvirtd
    daemon re-exporting the libvirt.so symbols. This means that at the
    time the modules are linked, they contain a huge number of undefined
    symbols. It also means that these undefined symbols are not versioned,
    so despite us providing a LIBVIRT_PRIVATE_XXXX version that
    intentionally changes on every release, the loadable modules could
    actually be loaded into any libvirtd regardless of version.
    
    This change explicitly links all modules against libvirt.so so
    that they don't rely on the re-export behave and can be fully resolved
    at build time. This will give us a stronger guarantee modules will
    actually be loadable at runtime and that we're using modules from the
    matched build.
    
    Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx>

Jirka

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel