Re: build problems on old Linux libc5

[Alain Guibert]

Hi Bruno, and much thanks for your interest,

 On Wednesday, April 2, 2008 at 0:07:10 +0200, Bruno Haible wrote:

> Thanks for reporting this (although we intend to minimize our efforts for
> such extremely old platforms).

These efforts are much appreciated, thanks Bruno!


> The behaviour change in "checking for long long int" is intended. The
> users of the gnulib macros now expect to be able to use long longs in
> preprocessor directives (even if there are some known bugs with values
> outside the 32-bit 'int' range).

But the preprocessor can define and assign long longs, and the compiler
is able to do everything with them. Not defining HAVE_LONG_LONG_INT may
waste this capacity, no?


> Regarding the four other failures, I cannot guess what the problem is
> with the little info that you gave.

I fear gdb breakpoints to be over me. But maybe some debug printfs can
already give some hints:

>>| FAIL: test-c-strcase.sh

Rather strange: LC_ALL=fr_FR setlocale(LC_ALL, "") returns NULL, and
following setlocale(LC_ALL, NULL) return "C". Outside of gettext, a
simple test program shows that setlocale() works normally and returns
"fr_FR" in both cases. If test-c-strn?casecmp.c are built with an -lc
inserted *before* /tmp/gettext-0.17/gettext-tools/intl/.libs/libintl.so,
then setlocale() behaves normally, and test-c-strcase.sh PASSes.


>>| checking for snprintf... yes
>>| test-snprintf.c:61: assertion failed
>>| FAIL: test-snprintf

Inserting a printf just before line 61:

| size=0 buf+size=12345
| size=1 buf+size=2345
| test-snprintf.c:62: assertion failed

It seems that libc snprintf() behaves as expected when size is 2 or
more. But when size is 0 or 1, retval = -1 and buf is fully overwritten.
Size 0 succeeds the ASSERT only because 0 bytes are compared.


>>| checking for vsnprintf... yes
>>| test-vsnprintf.c:74: assertion failed
>>| FAIL: test-vsnprintf

Same problem. The for loop modified to check sizes 0 and from 2 to 8
PASSes. But size 1 FAILs.


>>| checking for wcwidth... no
>>| test-wcwidth.c:45: assertion failed
>>| FAIL: test-wcwidth

wcwidth(32)=-1, and the same for all ASCII characters. I tried to modify
rpl_wcwidth(), but the test was not impacted: I suppose the test uses
the previously installed rpl_wcwidth(), not the one being built?


Alain.