Re: Testsuite of libidn 1.20 fails in gnulib

[Simon Josefsson]

Thanks Dagobert for the report and Paul for debugging this.

Paul Eggert <address@hidden> 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:

address@hidden:~/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
address@hidden:~/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