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é <berra...@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 <berra...@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 :| _______________________________________________ Xen-devel mailing list Xenemail@example.com https://lists.xenproject.org/mailman/listinfo/xen-devel