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

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(a)redhat.com&gt; 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(a)redhat.com&gt;