[Top][All Lists]
[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