Re: locale problem with make check

["Troy" <tjk at tksoft dot com>]

I am still trying to get the compile to work.

Here is some more info on the problem with skeleton.c, at about line 302:

I added some debugging lines, and I found out that just before the assertion 
fails, this is what we see:

__FUNCTION__: gconv 
outbufstart: 0xbfffd854
*outbufstart: 0 
do_flush: 0x4010b1b4

What is different is that do_flush is otherwise always 1 or 2 or something
else pretty low. I added a check to print the value whenever it's over 
0xffff or below 0. Only the run where assert() fails reported a value in
those ranges.


I fail to see the magic in the do_flush value.

Anyone else see any clues to solve this problem?


Thanks,


Troy






> 
> 
> I am trying to build glibc-2.2.4 and "make check" fails
> with an error from msgfmt. I searched the archives, and 
> found some people with the same error, but no solution
> to the problem.
> 
> The error says: 
> 
> msgfmt: ../iconv/skeleton.c:302: gconv: Assertion `outbufstart == ((void *)0)' failed.
> make[2]: *** [/usr/local/src/glibc-2.2.4-build/intl/tst-gettext.out] Error 134
> 
> The line in skeleton.c says:
> 
> if (__builtin_expect (do_flush, 0)) {
>       /* This should never happen during error handling.  */
>       assert (outbufstart == NULL);
>       status = __GCONV_OK;
> 
> 
> 
> The error is generated by ../glibc-2.2.4/intl/tst-gettext.sh
> on the line which runs the following command:
> msgfmt -o ${objpfx}domaindir/existing-locale/LC_MESSAGES/existing-domain.mo \
>        ../po/de.po
> 
> Which translates to:
> msgfmt -o /usr/local/src/glibc-2.2.4-build/intl/domaindir/existing-locale/LC_MESSAGES/existing-domain.mo 
> 	../po/de.po
> 
> 
> I ran the above msgfmt call under strace and found out that the skeleton.c file gets involved
> because msgfmt loads 
> /usr/local/src/glibc-2.2.4-build/iconvdata/ISO8859-1.so
> 
> The assert() error is generated immediately after loading ISO8859-1.so
> 
> It takes several hours to run make and make check. This is why I haven't
> tested every possible configuration option. E.g. I am not sure how the 2.4
> kernel or i386 options impact the gettext functions. I chose to use 2.4. because 
> that's the latest kernel, and one I need. There was no reference to using a 
> 2.4. kernel in the docs, so this has been guesswork. I would like to use the same 
> clib on other machines, which is why I used the i386 and kernel 2.2.10 options.
> 
> 
> My environment is as follows:
> 
> Mobile Pentium MMX 266 (i586 unknown)
> Linux kernel 2.4.9
> glibc 2.1.1
> gcc 2.95.3
> GNU Make 3.79.1
> msgfmt (GNU gettext) 0.10.40
> 
> 
> glibc-2.2.4 attempted as follows:
> 
> Sources: /usr/local/src/glibc-2.2.4/
> Build:   /usr/local/src/glibc-2.2.4-build/
> 
> The only package added was glibc-linuxthreads-2.2.4.
> 
> CFLAGS=-mcpu=i386 ../glibc-2.2.4/configure --prefix=/usr --enable-add-ons --enable-kernel=2.2.10 
> --host=i386-pc-linux-gnu  --with-headers=/usr/src/linux-2.4.9/include
> 
> 
> Running make failed at first. I needed to apply the following fixes to get
> it to work:
> 
> 1. compile died with the following error:
>    spinlock.c:107: inconsistent operand constraints in an `asm'
>    __asm __volatile ("" : "=m" (lock->__status) : "0" (lock->__status));
>    The following line, instead of the one above fixes the problem (someone had
>    posted the fix at http://gcc.gnu.org/ml/gcc-bugs/2001-06/msg00050.html.)
>    __asm __volatile ("" : "+m" (lock->__status));
> 2. cpp/cpp wasn't found. Fixed with the following two commands:
>    ln -s `which cpp` /lib/cpp
>    ln -s `which cpp` /usr/ccs/lib/cpp/cpp
> 
> After applying these fixes, make succeeded.
> 
> 
> Someone had the same skeleton.c problem on glibc mailing list,
> and their problem was traced back to a missing locale link. So I did
> the following:
> ln -s /usr/local/share/locale /usr/lib/locale
> (That's my directory for the locale files, and the one used by the current gettext 
> distro as well.  /usr/share/locale doesn't exist.)
> 
> 
> The fix didn't help in my case.
> 
> 
> If there is something I have overlooked, I will gladly provide the 
> info and investigate further. 
> 
> 
> Thanks,
> 
> 
> Troy
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>