Yet another instance of the GNU people fucking up. This is both laughable and sad.
I noticed this while trying to build libogg in parallel mode. It fails because it tries to create the same directory twice at the same time. Looking more closely, it uses a variable, mkdir_p, to try and create that directory. On OpenBSD, this variable ends up being install_sh -d, which does not copy at all with race conditions. The sad part is the automake test. If you look closely at the generated configure, you'll see it goes to great length to try to ensure that mkdir -p -- directory does the right thing, which is cool. Then it breaks it all by insisting that mkdir --version works, which uniquely identifies gnu mkdir. The really funny part is the reason for this test: some OSes have a mkdir -p that's broken, in the sense that it can't cope with part of the path suddenly appearing under its feet, in which case it will report an error---in fact, it was the case under OpenBSD up until OpenBSD 2.4, where niklas@ fixed the issue (yeah, basically it's been working forever...) So, people identified a case where mkdir -p doesn't work, and they added a misguided test that extends this case to whatever OS does not have gnu mkdir... in which case they replace a possibly broken mkdir -p with install_sh -d... which is BROKEN 100% OF THE TIME. Nice going ! how can such fuck-ups happen, I am still wondering ? Of course, this is an autoconf macro which does NOT end in the cache, so there is no easy fix at the configure level, except to regenerate all configure scripts with fixed automake macros... For now, the only solution that works (and I am considering it) is to enforce mkdir_p='mkdir -p --' in MAKE_FLAGS when CONFIGURE_STYLE=gnu or better. We could also get our mkdir to recognize --version, or create a wrapper to mkdir that recognizes --version, but this is disgusting. I am also trying to beat some sense into the automake people, so that in ten years time, when people start regenerating their configure files with the newer stable automake that integrates that fix (which will be released five years from now, hopefully), we might benefitting from that fix...
