undefined symbols in uclibc from today

[Khem Raj]

Thanks Denys for hunting it down.

On Tue, Nov 25, 2008 at 6:29 AM, Filippo ARCIDIACONO
<filippo.arcidiacono at st.com> wrote:
>
>
>> -----Original Message-----
>> From: uclibc-bounces at uclibc.org
>> [mailto:uclibc-bounces at uclibc.org] On Behalf Of Khem Raj
>> Sent: Sunday, November 23, 2008 9:22 AM
>> To: Denys Vlasenko
>> Cc: uclibc at uclibc.org
>> Subject: Re: undefined symbols in uclibc from today
>>
>> On Sat, Nov 22, 2008 at 6:39 AM, Denys Vlasenko
>> <vda.linux at googlemail.com> wrote:
>> > 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.
>>
>> Well no blame game here. I am just saying that earlier this
>> symbol was exported even if locales were not configured. But
>> now with your patch its doing the right thing.
>>
>> > 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.
>>
>> yeah thats what I figured out.
>>
>> >
>> > But maybe, if locale support is configured out, wcsxfrm()
>> should still
>> > be present, and work as if C locale is in effect?
>>
>> Yeah probably I should just enable locales end of story.
> IMO the function wcsxfrm() have to be defined without UCLIBC_HAS_LOCALE
> Enabled. After some investigation I had fix the problem adding
> libc_hidden_def(wcsxfrm) in libc/string/strlcpy.c (included by wcslcpy.c).
> When locale is on the wcsxfrm() function is defined in _collate.c
> (included by wcsxfrm.c).
>
>>
>> >
>> > --
>> > vda
>> >
> Cheers,
> Filippo.
>> _______________________________________________
>> uClibc mailing list
>> uClibc at uclibc.org
>> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
>>
>
>