Recent changes in autotools.eclass have caused econf failure in app-i18n/uim-1.7.3. Reproducible: Always Steps to Reproduce: 1. emerge uim With the following patch, I could avoid this econf failure. --- autotools.eclass.org +++ autotools.eclass @@ -165,7 +165,6 @@ # Run all the tools before aclocal so we can gather the .m4 files. local i tools=( # <tool> <was run> <command> - gettext false "eautopoint --force" # intltool must come after autopoint. intltool false "autotools_run_tool intltoolize --automake --copy --force" libtool false "_elibtoolize --install --copy --force"
Created attachment 313081 [details] build.log
I doubt your solution can get accepted, otherwise bug 416789 would have been resolved differently. Now one that could get accepted, would be something like cp ${S}/po/Makefile.in.in ${S}/qt/chardict/po/Makefile.in cp ${S}/po/Makefile.in.in ${S}/qt4/chardict/po/Makefile.in after eautoreconf.
(In reply to comment #2) > I doubt your solution can get accepted, otherwise bug 416789 would have been > resolved differently. > > Now one that could get accepted, would be something like > cp ${S}/po/Makefile.in.in ${S}/qt/chardict/po/Makefile.in > cp ${S}/po/Makefile.in.in ${S}/qt4/chardict/po/Makefile.in > > after eautoreconf. My patch may not be a good solution, but this bug isn't related to neither qt/chardict/po/ nor qt4/chardict/po/ because uim-1.8.0 doesn't have these directories and emerging uim-1.8.0 fails with the same error. Is there any other solution for this bug?
FYI, configure.ac in uim uses IT_PROG_INTLTOOL.
Bah, silly typo, it should have been: cp ${S}/po/Makefile.in.in ${S}/qt/chardict/po/Makefile.in.in cp ${S}/po/Makefile.in.in ${S}/qt4/chardict/po/Makefile.in.in or simply cp ${S}/po/Makefile.in.in ${S}/qt/chardict/po/ cp ${S}/po/Makefile.in.in ${S}/qt4/chardict/po/ The problems lies in autopoint being significantly more creative in seaching for its Makefile.in.in than intltolize. The directories are definitely there - your build log says so.
...oh, you mean in 1.8.0 ? But that would mean it's does not fail with *the same* error.
(In reply to comment #6) > ...oh, you mean in 1.8.0 ? > But that would mean it's does not fail with *the same* error. Sorry, the reason why I failed to emerge uim 1.8.0 is that my Gentoo environment was broken. After I fixed my env, I could emerge uim 1.8.0 successfully. Anyway, app-i18n/uim-1.7.3 is still broken. autogen.sh in uim 1.7.3 may help Gentoo devs fix this bug. The autogen.sh in uim 1.7.3 is messy, http://uim.googlecode.com/svn/tags/uim-1.7.3/autogen.sh compared with that in uim 1.8.0: http://uim.googlecode.com/git-history/uim-1.8.0/autogen.sh
Fix is in the tree.Thanks for your help.