Thanks Dagobert for the report and Paul for debugging this. Paul Eggert <egg...@cs.ucla.edu> writes:
> That problem is occurring because libidn is using an old > version of gnulib's m4/longlong.m4. This bug was fixed > on 2007-11-12 in gnulib. Time to upgrade, I expect. > > Plus, the libidn maintainers might consider upgrading from > gnulib regularly, before doing a libidn release. We do, the libidn 1.20 release contains uptodate gnulib since just a few days ago. I looked at longlong.m4 in libidn git master and it is the same as in gnulib: jas@latte:~/src/libidn$ sha1sum gl/m4/longlong.m4 lib/gl/m4/longlong.m4 ../gnulib/m4/longlong.m4 c11ba4d043cb4c07210b65152e46d8592ba7334a gl/m4/longlong.m4 c11ba4d043cb4c07210b65152e46d8592ba7334a lib/gl/m4/longlong.m4 c11ba4d043cb4c07210b65152e46d8592ba7334a ../gnulib/m4/longlong.m4 jas@latte:~/src/libidn$ The reason an older longlong.m4 ends up in the *.tar.gz archive is proabably that autoreconf --install (gettextize) pulls in an old longlong.m4: test -f ./configure || autoreconf --install ... Copying file m4/longlong.m4 (I'm surprised the longlong.m4 from gettext 0.18.1, which I'm using straight from Debian Squeeze, is from 2007. autopoint --version includes 2010 copyright years.) What's a good way to avoid having 'autoreconf --install' copy these old files? The workaround recommended in the gnulib manual doesn't work for me because I don't want people to have 'gnulib-tool' in order to build libidn from git. Is another workaround to overwrite all M4 files (and config.rpath) installed by autopoint with the gnulib version? I'll see if I can get that scheme to work. /Simon
