[libvirt] Likely build race, "/usr/bin/ld: cannot find -lvirt"
Daniel P. Berrangé
berrange at redhat.com
Tue Jun 12 14:39:09 UTC 2018
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 at redhat.com>
> 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 at redhat.com>
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 :|
More information about the libvir-list
mailing list