Hi Simon, Am 05.03.2011 um 12:22 schrieb Simon Josefsson: > 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.
would you mind also applying the fix-to-come to the current version of GNU SASL as it suffers from the same issue? http://lists.gnu.org/archive/html/help-gsasl/2010-12/msg00002.html Best regards -- Dago
