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

[Daniel P. Berrangé <berrange@xxxxxxxxxx>]

On Tue, Jun 12, 2018 at 04:16:53PM +0200, Jiri Denemark wrote:
> 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.

What I find strange is that automake has chosen to wire up

   install-modLTLIBRARIES

to the install-data-am target, instead of the install-exec-am target.

  mod_LTLIBRARIES =
  ....
  moddir = $(libdir)/libvirt/connection-driver
  ...
  mod_LTLIBRARIES += libvirt_driver_lxc.la

I would have expected the _LTLIBRARIES suffix to cause it to be wired
into the install-exec-am target


> 
> 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? :-)

The attractive big hammer solution is to stop using libtool entirely
and create shared libraries directly with gcc -shared, thus getting
rid of the stupid shell wrapper scripts & relinking that libtool
does....


> 
> 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>

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 :|

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