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: | Library | Assignee: | 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
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) |
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.