undefined symbols in uclibc from today

Denys Vlasenko vda.linux at googlemail.com
Sat Nov 22 14:39:41 UTC 2008


On Saturday 22 November 2008 07:24, Khem Raj wrote:
> Hmm so this wcsxfrm is guarded by UCLIBC_HAS_LOCALE config option.
> your patch just exposed it.

If you are saying that I am not guilty that's nice to hear,
bur I am also interested how exactly my patch exposed that.
Can you describe in more details?

> I thought they should be wide char 
> routines and I do have wide char support turned on in config.

Manpage seems to say that it is locale-related indeed:

       size_t wcsxfrm(wchar_t *restrict ws1, const wchar_t *restrict ws2,
              size_t n);
DESCRIPTION
       The  wcsxfrm()  function  shall  transform  the  wide-character  string
       pointed to by ws2 and place the resulting  wide-character  string  into
       the  array  pointed to by ws1. The transformation shall be such that if
       wcscmp() is applied to two transformed wide strings, it shall return  a
       value  greater  than,  equal  to,  or less than 0, corresponding to the
       result of wcscoll() applied to the  same  two  original  wide-character
       strings.

The point is, wcscoll() is a locale function:

       The  wcscoll() function shall compare the wide-character string pointed
       to by ws1 to the wide-character string pointed to by ws2,  both  inter-
       preted as appropriate to the LC_COLLATE category of the current locale.

thus wcsxfrm() has to understand locale to work properly.

But maybe, if locale support is configured out, wcsxfrm() should
still be present, and work as if C locale is in effect?

--
vda



More information about the uClibc mailing list