Bug 66413

Summary: libxcb 1.9.1: Fails to build on Arch Linux: /home/<user>/install-sh: No such file or directory
Product: XCB Reporter: Alain Kalker <a.c.kalker>
Component: LibraryAssignee: xcb mailing list dummy <xcb>
Status: RESOLVED FIXED QA Contact: xcb mailing list dummy <xcb>
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: Build log
Install log
Patch reordering the initialization of Automake
log of "autoreconf -v -v --install " without patch applied
log of "autoreconf -v -v --install " _with_ configure.ac patch applied

Description Alain Kalker 2013-06-30 19:41:18 UTC
Trying to build on Arch Linux (using Automake 1.14, Autoconf 2.69), I get the following error during 'make install' (full log attached):

Making install in doc
make[1]: Entering directory `/home/miki/pkg/abs/extra/libxcb/src/libxcb-1.9.1/doc'
make[2]: Entering directory `/home/miki/pkg/abs/extra/libxcb/src/libxcb-1.9.1/doc'
make[2]: Nothing to be done for `install-exec-am'.
/bin/sh /home/miki/install-sh -d '/home/miki/pkg/abs/extra/libxcb/pkg/libxcb/usr/share/doc/libxcb'
/bin/sh: /home/miki/install-sh: No such file or directory
make[2]: *** [install-data-local] Error 127
make[2]: Leaving directory `/home/miki/pkg/abs/extra/libxcb/src/libxcb-1.9.1/doc'
make[1]: *** [install-am] Error 2
make[1]: Leaving directory `/home/miki/pkg/abs/extra/libxcb/src/libxcb-1.9.1/doc'
make: *** [install-recursive] Error 1

After some searching and experimenting, I have found that reordering the initialization of Automake in configure.ac (see attached patch) resolves the issue (and also removes a warning about a missing or too old 'missing' file.
Comment 1 Alain Kalker 2013-06-30 19:43:34 UTC
Created attachment 81756 [details]
Build log
Comment 2 Alain Kalker 2013-06-30 19:44:07 UTC
Created attachment 81757 [details]
Install log
Comment 3 Alain Kalker 2013-06-30 19:44:52 UTC
Created attachment 81758 [details] [review]
Patch reordering the initialization of Automake
Comment 4 Alain Kalker 2013-06-30 19:53:54 UTC
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/
Comment 5 Uli Schlachter 2013-06-30 19:54:20 UTC
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"?
Comment 6 Alain Kalker 2013-06-30 20:29:40 UTC
Created attachment 81765 [details]
log of "autoreconf -v -v --install " without patch applied
Comment 7 Alain Kalker 2013-06-30 20:30:39 UTC
Created attachment 81766 [details]
log of "autoreconf -v -v --install " _with_ configure.ac patch applied
Comment 8 Alain Kalker 2013-06-30 20:33:50 UTC
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?
Comment 9 Alain Kalker 2013-06-30 20:48:36 UTC
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 ;-)
Comment 10 Daniel Martin 2013-07-01 23:44:44 UTC
(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.
Comment 11 Daniel Martin 2013-07-02 06:58:50 UTC
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.)
Comment 12 Alain Kalker 2013-07-02 14:43:31 UTC
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.
Comment 13 Alain Kalker 2013-07-02 16:02:46 UTC
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).
Comment 14 Alain Kalker 2013-07-02 16:08:09 UTC
Link to bug-autoconf mail archive for this bug: http://lists.gnu.org/archive/html/bug-autoconf/2013-07/msg00000.html
Comment 15 Daniel Martin 2013-07-02 17:31:16 UTC
(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.
Comment 16 Alain Kalker 2013-07-02 18:22:50 UTC
(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.
Comment 17 Daniel Martin 2013-07-25 10:11:07 UTC
(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
Comment 18 Alain Kalker 2013-07-26 20:07:39 UTC
(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.
Comment 19 Uli Schlachter 2013-08-20 14:44:04 UTC
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)

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.