bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Testsuite of libidn 1.20 fails in gnulib


From: Dagobert Michelsen
Subject: Re: Testsuite of libidn 1.20 fails in gnulib
Date: Sun, 6 Mar 2011 22:48:17 +0100

Hi Simon,

Am 05.03.2011 um 12:22 schrieb 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.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]