Description of problem: When doing an out of source build (which is now required), in parallel, libvirt 5.10.0 fails to build sometimes, trying to access files in the directory build/src/access which does not exist yet, though the directory does exist in the tarball's src directory. (So far I have only seen the problem when building universal (for both x86_64 and i386 simultaneously), but there's no reason to believe that's the only way to trigger the bug.) When NOT building in parallel, the build/src/access directory is created (copied from the tarball's src directory?) first and the build succeeds. So I suspect the dependencies of at least one of the targets in the Makefile are not complete. Version-Release number of selected component (if applicable): 5.10.0 How reproducible: Sometimes Steps to Reproduce: 1. mkdir build && cd build 2. CFLAGS="-arch x86_64 -arch i386" LDFLAGS="-arch x86_64 -arch i386" ../libvirt-5.10.0/configure 3. make -j8 Actual results: Build fails: /opt/local/bin/perl5 -w ../../libvirt-5.10.0/src/rpc/gendispatch.pl --mode=aclheader \ remote REMOTE ../../libvirt-5.10.0/src/remote/remote_protocol.x \ > access/viraccessapicheck.h /opt/local/bin/perl5 -w ../../libvirt-5.10.0/src/rpc/gendispatch.pl --mode=aclbody \ remote REMOTE ../../libvirt-5.10.0/src/remote/remote_protocol.x access/viraccessapicheck.h \ > access/viraccessapicheck.c /opt/local/bin/perl5 -w ../../libvirt-5.10.0/src/rpc/gendispatch.pl --mode=aclheader \ qemu QEMU ../../libvirt-5.10.0/src/remote/qemu_protocol.x \ > access/viraccessapicheckqemu.h /opt/local/bin/perl5 -w ../../libvirt-5.10.0/src/rpc/gendispatch.pl --mode=aclbody \ qemu QEMU ../../libvirt-5.10.0/src/remote/qemu_protocol.x access/viraccessapicheckqemu.h \ > access/viraccessapicheckqemu.c /bin/sh: access/viraccessapicheck.h: No such file or directory /bin/sh: access/viraccessapicheckqemu.h: No such file or directory /bin/sh: access/viraccessapicheck.c: No such file or directory make[2]: *** [access/viraccessapicheck.h] Error 1 make[2]: *** Waiting for unfinished jobs.... Expected results: Successful build Additional info: I'm the maintainer of libvirt in MacPorts. libvirt 5.9.0 and earlier built fine both universal and using a parallel build but I was NOT doing an out of source build.
Created attachment 1645044 [details] build failure log
Sorry, I should have tested more thoroughly before submitting. It does not have anything to do with building parallel after all. It does appear to be specific to building for i386, or perhaps any 32-bit arch. How reproducible: Always Steps to Reproduce: 1. mkdir build && cd build 2. CFLAGS="-arch i386" LDFLAGS="-arch i386" ../libvirt-5.10.0/configure 3. make Actual results: Build fails: /opt/local/bin/perl5 -w ../../libvirt-5.10.0/src/rpc/gendispatch.pl --mode=aclheader \ remote REMOTE ../../libvirt-5.10.0/src/remote/remote_protocol.x \ > access/viraccessapicheck.h /bin/sh: access/viraccessapicheck.h: No such file or directory
Created attachment 1645057 [details] i386 build failure log
I am sorry again, I seem to be too tired to report bugs properly. The log I attached was actually for a universal build, not for an i386-only build. Let's just leave it at: there is a build failure that happens sometimes but I don't know why.
We've previously seen this when people build with --disable-dependency-tracking Even if you don't have that arg, it is worth trying to add an explicit --enable-dependency-tracking in case the macOS default for this arg is different from that we see on Linux.
You're right, I was using --disable-dependency-tracking. MacPorts adds this flag automatically when building autotools-based projects universal, because we had previously found that many projects would fail to build universal unless we did that. However, in the case of libvirt, leaving dependency tracking enabled even when building universal seems to work fine, so I'll do that. Thanks for the suggestion.
Ok, that's good to hear. I'll close this bug as we don't intend to investigate why --disable-dependancy-tracking breaks things. In the first quarter of next year we will be replacing autotools with meson for libvirt's build process.