[libvirt] [PATCH 1/4] fix problem with MKDIR_P vs mkdir_p

[Jim Meyering]

Maximilian Wilhelm <max at rfc2324.org> wrote:
> Anno domini 2009 Jim Meyering scripsit:
>
>> Maximilian Wilhelm <max at rfc2324.org> wrote:
>> > configure defines mkdir_p but src/Makefile.am uses MKDIR_P
>> > ---
>> >  src/Makefile.am |    2 ++
>> >  1 files changed, 2 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/src/Makefile.am b/src/Makefile.am
>> > index 9d934b4..eff9039 100644
>> > --- a/src/Makefile.am
>> > +++ b/src/Makefile.am
>> > @@ -589,6 +589,8 @@ endif
>> >  endif
>> >  EXTRA_DIST += $(LXC_CONTROLLER_SOURCES)
>> >
>> > +MKDIR_P = $(mkdir_p)
>> > +
>> >  install-exec-local:
>> >  	$(MKDIR_P) "$(DESTDIR)$(localstatedir)/cache/libvirt"
>> >  	$(MKDIR_P) "$(DESTDIR)$(localstatedir)/lib/libvirt/images"
>
>> This is just a symptom of your using a version of automake that is too old.
>
> Oh thanks for the hint. We had to downgrade autoake to 1.9 for building
> software for other systems...

Be aware that in using versions of automake and autoconf that are too
old, you are in effect reintroducing bugs that have long since been
fixed.  Be especially careful not to distribute for general use
any distribution tarballs you make based on those older versions.
And note that even for your own use, relying on automake-generated
Makefiles is risky.  For example, automake-1.9 has a bug (fixed in 1.10)
that can make parallel builds thread-unsafe -- coincidentally, due to
problems with detecting a working "mkdir -p", which is sometimes used
for locking.

> The usual auto*-fun.

Be sure to prod the maintainers of any packages that require
anything older than the latest upstream stable releases of
automake or autoconf.