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