On Sun, 24 Jan 2021, Paul Eggert wrote:
On 1/23/21 4:06 PM, Bob Friesenhahn wrote:
A tiny fork/exec is not a big deal.
It is indeed not a big deal. That being said, one can optimize away GNU
make's fork and exec by using "@:" instead of "@true".
At the moment it is a big deal for me because the locking prototol
that Autoconf/Automake is using does not work with NFS mounts for
Illumos-derived systems when the client is also an Illumos-derived
system, because Illumos failed to support the legacy locking protocol
used when the system locking daemon was re-implemented from scratch.
If the NFS client of the Illumos-based NFS server is GNU/Linux, then
everything works just fine due to GNU/Linux implementing a fall-back
mechanism to use POSIX locking if the server says it does not support
the legacy lock protocol.
It is likely that a small patch to Automake Perl-based locking code
could solve this issue by using the same fall-back to using POSIX
locking rather than legacy locking the same way that GNU/Linux does.
It may also be that using POSIX locking in the first place is the
solution.
What happens is that any parallel builds which cause Autotools to
invoke Perl's legacy locking code will fail, which means that I can't
use parallel builds until it has done what it needs to do. So the
build goes about 20x slower.
For my personal development environment, the container ('zone') which
is doing the NFS mount does not have to use NFS (because it is running
on the same host as the file server) but I have not taken time to
learn how to update the container definition.
Bob
--
Bob Friesenhahn
bfriesen@xxxxxxxxxxxxxxxxxxx, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
