Simon Josefsson <[EMAIL PROTECTED]> writes: >>> Btw, I tried to install gettext 0.17 under /usr/local, but gettextize >>> didn't seem to install the *.m4 files from /usr/local anyway, instead I >>> got the lib-link file from /usr. >> >> If you installed gettext with --prefix=/usr/local, and call gettextize from >> /usr/local/bin/, it will use the *.m4 files from /usr/local/share/aclocal/. >> (Look at the variables 'prefix' and 'datarootdir' in this script.) > > That wasn't my experience, although I invoked 'autoreconf' and not > gettextize directly. Maybe autoreconf do not call gettextize from PATH? > /usr/local/bin is before /usr/bin for me. I'll see if I can reproduce > this if it would help debugging.
I discovered the problem -- it seems autopoint is checking out the lib-link.m4 from the CVS repository in /usr/local/share/gettext/archive.tar.gz, and it is using the AM_GNU_GETTEXT_VERSION version to indicate which version to checkout. Since GnuTLS' configure.in says 0.16 (I see no reason to change it to 0.17?), I get the old lib-link.m4 file. The gettext manual confuses me here, it says: When the maintainer then runs gettextize from, say, version 0.12.1 on the package, the occurrence of `AM_GNU_GETTEXT_VERSION(0.11.5)' will be changed into `AM_GNU_GETTEXT_VERSION(0.12.1)', and all other developers that use the CVS will henceforth need to have GNU `gettext' 0.12.1 or newer installed. That changing doesn't seem to happen, after running gettextize, it still says 0.16 for me. So I think the only solution is for me to arrange for the gnulib files to overwrite the gettextize files, assuming it is safe to use the gnulib files together with gettext 0.16. Alternatively, wait for gettext 0.17 to hit Debian testing and bump the gettext version requirement, although if I run into the same problem again I'll have to pull in the gnulib files anyway. /Simon
