[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion 1.9.10/1.10.4 choke on non-ASCII resources on HP-UX

From: Branko Čibej <brane_at_apache.org>
Date: Tue, 7 May 2019 09:53:08 +0200

On 07.05.2019 08:45, Osipov, Michael wrote:
>
>
> Am 2019-05-03 um 11:53 schrieb Branko Čibej:
>> On 02.05.2019 11:40, Osipov, Michael wrote:
>>> Hi Branko,
>>>
>>> Am 2019-05-01 um 02:17 schrieb Branko Čibej:
>>>> On 30.04.2019 20:18, Osipov, Michael wrote:
>>>>
>>>>> The terminal and locale are fine though:
>>>>>> $ locale
>>>>>> LANG=de_DE.utf8
>>>>>> LC_CTYPE="de_DE.utf8"
>>>>>> LC_COLLATE="de_DE.utf8"
>>>>>> LC_MONETARY="de_DE.utf8"
>>>>>> LC_NUMERIC="de_DE.utf8"
>>>>>> LC_TIME="de_DE.utf8"
>>>>>> LC_MESSAGES="de_DE.utf8"
>>>>>> LC_ALL=
>>>>
>>>> LC_ALL should probably not be empty. Could be that on HP-UX, the empty
>>>> value causes Subversion to use the default C (or POSIX) locale. Try
>>>> setting
>>>>
>>>>       LC_ALL="de_DE.utf8"; export LC_ALL
>>>>
>>>> Subversion tries setlocale(LC_ALL, "") first and only if that
>>>> fails, it
>>>> tries setlocale(LC_CTYPE, ""). Evidently the first call succeeds,
>>>> which
>>>> is strange but not strictly wrong. I think.
>>>
>>> Doesn't really work out.
>>>
>>> Here is the old server:
>>>> $ hostname
>>>> blnn724x
>>>> $ svn --version -q
>>>> 1.9.4
>>>> $ locale
>>>> LANG=de_DE.utf8
>>>> LC_CTYPE="de_DE.utf8"
>>>> LC_COLLATE="de_DE.utf8"
>>>> LC_MONETARY="de_DE.utf8"
>>>> LC_NUMERIC="de_DE.utf8"
>>>> LC_TIME="de_DE.utf8"
>>>> LC_MESSAGES="de_DE.utf8"
>>>> LC_ALL=
>>>> $ svn ls https://deblndw011x.ad001.siemens.net/repos/svn/Playground
>>>> README.txt
>>>> a/
>>>> c.txt
>>>> hallo.c
>>>> keyword-test.txt
>>>> test1234/
>>>> testprogramm.c
>>>> привет.txt
>>>
>>> the export didn't change anything, it still fails:
>>>> $ hostname
>>>> deblndw024v
>>>> $ svn --version -q
>>>> 1.9.4
>>>> $ locale
>>>> LANG=de_DE.utf8
>>>> LC_CTYPE="de_DE.utf8"
>>>> LC_COLLATE="de_DE.utf8"
>>>> LC_MONETARY="de_DE.utf8"
>>>> LC_NUMERIC="de_DE.utf8"
>>>> LC_TIME="de_DE.utf8"
>>>> LC_MESSAGES="de_DE.utf8"
>>>> LC_ALL=de_DE.utf8
>>>> $ svn ls https://deblndw011x.ad001.siemens.net/repos/svn/Playground
>>>> README.txt
>>>> a/
>>>> c.txt
>>>> hallo.c
>>>> keyword-test.txt
>>>> test1234/
>>>> testprogramm.c
>>>> {U+043F}{U+0440}{U+0438}{U+0432}{U+0435}{U+0442}.txt
>>>
>>>
>>> Here is a basic program:
>>>> 0# cat locale.c
>>>> #include <locale.h>
>>>> #include <stdio.h>
>>>> #include <langinfo.h>
>>>>
>>>> int main(void) {
>>>>      char *l = NULL;
>>>>      l = setlocale(LC_ALL, "");
>>>>      printf("%s\n", l);
>>>>      char *nl = NULL;
>>>>      nl = nl_langinfo(CODESET);
>>>>      printf("%s\n", nl);
>>>>
>>>>      return 0;
>>>> }
>>>> # aCC -o locale locale.c
>>> # ./locale
>>> C.utf8 C.utf8 C.utf8 C.utf8 C.utf8 C.utf8
>>> utf8
>>>> # LC_ALL=de_DE.utf8 ./locale
>>>> de_DE.utf8 de_DE.utf8 de_DE.utf8 de_DE.utf8 de_DE.utf8 de_DE.utf8
>>>> utf8
>>>
>>> Looks good to me, doesn't it?
>>
>> It does ...
>>
>>> Anything else I can try? Bad libiconv or libapr?
>>
>> Either libiconv or apr_xlate don't handle UTF-8 on HP-UX? It would be
>> strange but not impossible.
>>
>> Given the earlier warning from msgfmt that
>> "Charset "UTF-8" is not supported" I suspect libiconv, since gettext
>> doesn't use APR.
>>
>> Is it possible that you're using a mis-configured GNU libiconv instead
>> of the stock system version? Since locale() does support UTF-8, I'd
>> expect the stock libiconv to support it, too. However, IIRC GNU tools
>> don't like the POSIX libiconv API very much.
>>
>> Subversion doesn't care; for string conversion, whatever stock libiconv
>> does (through apr_xlate) should be enough; it doesn't depend on NLS
>> being enabled.
>
> Given your pointers, that was it. For some reason I have screwed up
> the stack around the GNU stuff. Recompiling everyting again to PREFIX
> made it work. Subversion perfectly works now on HP-UX.

Great!

-- Brane
Received on 2019-05-07 09:53:13 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.