Looking back at the original bug report
<https://trac.macports.org/ticket/63603> I now see this weird line:
rm:
confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---:
No space left on device
What's up with that "No space left on device" message? Can you confirm
that on macOS, an 'unlink' or 'rmdir' system call can fail because
you're out of disk space? Kinda weird, huh? Does this have something to
do with running the builds on a file system that maintains histories of
everything?
When the Gnulib test fails, is there a directory "confdir-14B---" left
behind such that "rm -rf confdir-14B---" does not remove it?
If not, then I'm not at all following what's going on.
If so, can we come up with some other command to remove that directory?
Something like this, perhaps?
(cd confdir-14B---/confdir-14B--- && rm -fr *)
rm -fr confdir-14B---
If that works, it should be easy to change gnulib/m4/getcwd-abort-bug.m4
to work around this macOS bug.
