For once comments welcome from developers, on how to solve this; I guess the problem is that we're updating the gettext macros, but we obviously don't run autopoint (and we shouldn't, it's most definitely *not* a safe thing to do), but that's going to be problematic. Please no comments from users reporting trouble, file a new bug for that!
On Solaris x86 prefix, all packages depending on gettext-0.18 fail to build, as does gettext-0.18 if emerge is invoked for it only.
(In reply to comment #1) > On Solaris x86 prefix, all packages depending on gettext-0.18 fail to build, as > does gettext-0.18 if emerge is invoked for it only. > I was able to build gettext-0.18.1.1 with the attached patch. It was failing due to invoking '/bin/sh' which is Bourne shell on Solaris 10, rather than '{$prefix}/bin/sh', a link to bash.
Created attachment 245280 [details, diff] patch for convert-archive.in to fix invocation of /bin/sh vs. linked bash
(In reply to comment #3) > Created an attachment (id=245280) [details] > patch for convert-archive.in to fix invocation of /bin/sh vs. linked bash > Why is this hardcoded to /opt/gentoo? My prefix is /Gentoo.
this is a tracker. do not post random comments/patches here. file a real bug.
What are best practice to fix for this issues? Does `cp /usr/share/gettext/po/Makefile.in.in <appropriate location>` is a good fix? Or may be we need some more general function into eclass?
i have no idea what issue you're referring to
(In reply to comment #7) > i have no idea what issue you're referring to > The one that has following output: make[...]: Entering directory `/tmp/foobar-1.0/po' *** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.17 but the autoconf macros are from gettext version 0.18 In which case it's enough to overwrite po/Makefile.in.in with the copy gettext installs to system. This should not be done based on USE="nls" but rather simply checking if the file exists, because `make` will enter the directory regardless if you asked for nls or not. So I suggest: local x=/usr/share/gettext/po/Makefile.in.in [[ -e $x ]] && cp -f $x po/ or something similar in the problematic packages src_prepare()
that output appears nowhere in this report, so Peter's comment lacks any sort of context. but at any rate ... does `autoreconf` not work ? it should run autopoint for you which should regenerate the gettext files.
(In reply to comment #9) > does `autoreconf` not work ? it should run autopoint for you which should > regenerate the gettext files. > no, it doesn't work (bug 336119). zaz runs eautoreconf, starts configure, and fails at the end... outdated Makefile.in.in
