Created attachment 81756 [details]
Build log

Created attachment 81757 [details]
Install log

Created attachment 81758 [details] [review]
Patch reordering the initialization of Automake

Note: the patching at the top of the attached build log is done by the PKGBUILD for libxcb[1] in Arch Linux, and is unrelated to this problem. My patch applies to clean configure.ac.

[1]: https://www.archlinux.org/packages/extra/x86_64/libxcb/

Uhm, I can't find anything in the auto* docs which say that a certain order of the macros is required. Could this be a bug in automake?

Also, does adding "--verbose" to the call to automake say anything about it installing "missing" and "install-sh"?

Created attachment 81765 [details]
log of "autoreconf -v -v --install " without patch applied

Created attachment 81766 [details]
log of "autoreconf -v -v --install " _with_ configure.ac patch applied

Logs of "autoreconf -v -v --install" attached, with and without the patch applied.
As you can see when you do a diff between them, ordering does seem to matter in practice. Perhaps an auto* bug, but if the patch works around it, isn't that what matters?

To clarify my previous comment: for users using non-buggy autotools, the change should amount to a no-op, while for users still using buggy autotools, the difference is between a build failure and a working build ;-)

(In reply to comment #5)
> Uhm, I can't find anything in the auto* docs which say that a certain order
> of the macros is required. Could this be a bug in automake?

Just had a look at it and I think it's bug in automake too. The problem seems to be that $ac_aux_dir is not initialized. Adding a AC_CONFIG_AUX_DIR or AC_CONFIG_AUX_DIR([.]) fixes it for me.

Long story:
- "/bin/sh: /home/miki/install-sh" comes from $install_sh,
- $install_sh comes out of install-sh.m4:
  ...
  install_sh="\${SHELL} $am_aux_dir/install-sh"
  ...
- $am_aux_dir comes out of auxdir.m4:
  ...
  am_aux_dir=`cd $ac_aux_dir && pwd`
  ...
- And if $ac_aux_dir is not initialized, we end up with the home directory as prefix in $am_aux_dir.

It was a bit late as I wrote this and I've forgotten to mention:
- that I've skimmed through the automake commits and couldn't find a commit, which could've caused this bug. On the other hand, it triggers only if DESTDIR doesn't exist prior and who knows when that was tested the last time.
- and I couldn't figure out why reordering fixes it. (Though I'm a m4 noob.)

Thanks for your excellent sleuthing to find out where this bug comes fron.

Just to add to your work:

-$ac_aux_dir may come from any of 3 places in general.m4

Considering your remark that adding AC_CONFIG_AUX_DIR macro is another alternative of resolving the issue, and that both ac_aux_dir and AC_CONFIG_AUX_DIR are defined as part of autoconf, I'm inclined to report it as a bug in autoconf first, and let upstream decide to wich autotool it should be assigned.

Reported upstream to bug-autoconf@gnu.org , with Subject: libxcb build failure: /bin/sh: /home/miki/install-sh: No such file or directory

Apparently, Autoconf doesn't have a bugtracker (anymore).

Link to bug-autoconf mail archive for this bug: http://lists.gnu.org/archive/html/bug-autoconf/2013-07/msg00000.html

(In reply to comment #14)
> Link to bug-autoconf mail archive for this bug:
> http://lists.gnu.org/archive/html/bug-autoconf/2013-07/msg00000.html

Thanks.

btw. You don't need to enforce python2 anymore. libxcb builds with python3 too.

(In reply to comment #15)
> btw. You don't need to enforce python2 anymore. libxcb builds with python3
> too.

Thanks for the tip! I will report it to the package maintainer.

(In reply to comment #14)
> Link to bug-autoconf mail archive for this bug:
> http://lists.gnu.org/archive/html/bug-autoconf/2013-07/msg00000.html
What a pitty, no reply yet.

But, I think moving the initialization of automake is the best fix. I've adjusted the patch slightly (do not move AC_PREREQ) and posted it on the list.
http://lists.freedesktop.org/archives/xcb/2013-July/008428.html

(In reply to comment #17)
> (In reply to comment #14)
> > Link to bug-autoconf mail archive for this bug:
> > http://lists.gnu.org/archive/html/bug-autoconf/2013-07/msg00000.html
> What a pitty, no reply yet.

Perhaps the bug title was a bit too uninteresting ;-)

> But, I think moving the initialization of automake is the best fix. I've
> adjusted the patch slightly (do not move AC_PREREQ) and posted it on the
> list.
> http://lists.freedesktop.org/archives/xcb/2013-July/008428.html

Thanks for the followup, hopefully there will be a fix either way.

commit 50fb3a6312dd0b6b613fc886ffd6827952d1e286
Author: Daniel Martin <consume.noise@gmail.com>
Date:   Wed Jul 24 12:51:04 2013 +0200

    Initialize automake earlier (bugfix for #66413)
    
    This fixes:
        https://bugs.freedesktop.org/show_bug.cgi?id=66413
        Bug 66413 - libxcb 1.9.1: Fails to build on Arch Linux: \
            /home/<user>/install-sh: No such file or directory
    
    Without that patch the search path for `install-sh` will become $HOME
    and the `install` target will fail, when DESTDIR doesn't exist in
    advance. (occured with automake 1.14 and autoconf 2.69)