You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@attglobal.net> on 2002/07/23 13:43:59 UTC
status (?) of current iconv breakage
Is anybody working on any of this? Am I confused about something?
1) APRUTIL_EXPORT_LIBS not used in Apache, so httpd won't load on some
platforms
2) apr_iconv_inbuf_const hints from apr_hints.m4 not migrated (to
where?)
3) APU_CHECK_ICONV_INBUF not working
config.log shows that a warning is generated from the test compile
but it does not set apu_iconv_inbuf_const on my RH-6.2/glibc-2.1.3
box
This seems to be because $GCC is not set in the apr-util so the
APR_TRY_COMPILE_NO_WARNING can't work when using gcc.
Does anyone know of other breakage?
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: status (?) of current iconv breakage
Posted by Jeff Trawick <tr...@attglobal.net>.
I should have clarified that these were build problems, not functional
problems.
Jeff Trawick <tr...@attglobal.net> writes:
> 1) APRUTIL_EXPORT_LIBS not used in Apache, so httpd won't load on some
> platforms
no, this wasn't a valid analysis... before and after the iconv move
we are adding -liconv to apache links...
I think it is that -liconv is not added to link of libaprutil.la... a
checkout from some days back shows that we used to add -liconv on the
link of libapr.la (where we used iconv), so getting those libraries
added on the link of libaprutil.la should make apr-util apps work on
aix and tru64 and whatever else...
> 2) apr_iconv_inbuf_const hints from apr_hints.m4 not migrated (to
> where?)
fixed
> 3) APU_CHECK_ICONV_INBUF not working
>
> config.log shows that a warning is generated from the test compile
> but it does not set apu_iconv_inbuf_const on my RH-6.2/glibc-2.1.3
> box
>
> This seems to be because $GCC is not set in the apr-util so the
> APR_TRY_COMPILE_NO_WARNING can't work when using gcc.
I don't have a plan for how to fix this at the moment.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: status (?) of current iconv breakage
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Jeff Trawick <tr...@attglobal.net> writes:
> Is anybody working on any of this? Am I confused about something?
>
> 1) APRUTIL_EXPORT_LIBS not used in Apache, so httpd won't load on some
> platforms
>
> 2) apr_iconv_inbuf_const hints from apr_hints.m4 not migrated (to
> where?)
>
> 3) APU_CHECK_ICONV_INBUF not working
>
> config.log shows that a warning is generated from the test compile
> but it does not set apu_iconv_inbuf_const on my RH-6.2/glibc-2.1.3
> box
>
> This seems to be because $GCC is not set in the apr-util so the
> APR_TRY_COMPILE_NO_WARNING can't work when using gcc.
>
> Does anyone know of other breakage?
Recently on the Subversion list, Mike Pilato asked Branko Čibej for a
summary what he knows about the current state of iconv breakage. Here
is Brane's response:
From: Branko Čibej <br...@xbc.nu>
Subject: Re: Alpha on Win32 without UTF8 conversion
To: cmpilato@collab.net
CC: dev@subversion.tigris.org
Date: Tue, 23 Jul 2002 04:12:50 +0200
cmpilato@collab.net wrote:
>Brane, if you can (pleeeeease) take the time to summarize briefly the
>problems you know of, and a checklist of whether or not you've got
>solutions for those problems (perhaps pending in mailing list
>archives), I'd be glad to take a stab at picking up where you left
>off.
>
O.K., here's a summary:
* Paths in APR:
o We must have a way to find out what encoding the file names
produced and consumed by APR have, because on WinNT, those
will always be in UTF-8, regardless of the current locale
settings. See my message and resulting thread in dev@apr:
Subject: [PATCH] Determining the character encoding used for paths in APR
* Determining the default locale encoding:
o apr_xlate.h defines APR_LOCALE_CHARSET, which you can pass
to apr_xlate_open to have it figure out the encoding used by
the current locale. The implementation is unix-only. I wrote
a patch for Windows; I'm attaching the relevant bits of that
patch.
o Now that apr_xlate is in apr-util, that patch has to be
broken out and the code moved into APR. I suggested two new
functions, apr_os_locale_encoding and
apr_os_default_encoding, that would replace the
get_locale_charset and get_default_charset in xlate.c.
* Getting a working iconv library
o apr-iconv isn't.
o I still think supporting GNU libiconv is the way to go. See
my mail in dev@subversion:
Subject: Re: Is --enable-utf8 working everywhere?
Message-ID: <3D...@xbc.nu>
Either the solition that detects and builds the
libiconv
sources, or one that detects and links with a pre-compiled
libiconv, would be fine. Note that we wouldn't distribute
any LGPL code, nor make libiconv binaries available -- just
tell users how to build them. For the win32 binaries on the
sownload site, it'd be quite enought to add a link to the
gnu site where the sources are available; it's not as if
we're changing that source.
Please ask if any of this isn't clear.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Index: i18n/unix/xlate.c
===================================================================
RCS file: /home/cvs/apr/i18n/unix/xlate.c,v
retrieving revision 1.28
diff -u -p -r1.28 xlate.c
--- i18n/unix/xlate.c 15 Jul 2002 19:21:01 -0000 1.28
+++ i18n/unix/xlate.c 17 Jul 2002 00:46:12 -0000
@@ -146,9 +146,21 @@ static const char *get_default_charset(v
* defer to get_default_charset().
*/
-static const char *get_locale_charset(void)
+static const char *get_locale_charset(apr_pool_t *pool)
{
-#if defined(HAVE_NL_LANGINFO) && defined(HAVE_CODESET)
+#ifdef WIN32
+ /* ### Yes, this is a hack and doesn't belong in this file.
+ Will fix soonest. --brane */
+ LCID locale = GetThreadLocale();
+ int len = GetLocaleInfo(locale, LOCALE_IDEFAULTANSICODEPAGE, NULL, 0);
+ char *cp = apr_palloc(pool, len + 2);
+ if (0 < GetLocaleInfo(locale, LOCALE_IDEFAULTANSICODEPAGE, cp + 2, len))
+ {
+ cp[0] = 'C';
+ cp[1] = 'P';
+ return cp;
+ }
+#elif defined(HAVE_NL_LANGINFO) && defined(HAVE_CODESET)
const char *charset;
charset = nl_langinfo(CODESET);
if (charset) {
@@ -158,13 +170,13 @@ static const char *get_locale_charset(vo
return get_default_charset();
}
-static const char *handle_special_names(const char *page)
+static const char *handle_special_names(const char *page, apr_pool_t *pool)
{
if (page == APR_DEFAULT_CHARSET) {
return get_default_charset();
}
else if (page == APR_LOCALE_CHARSET) {
- return get_locale_charset();
+ return get_locale_charset(pool);
}
else {
return page;
@@ -236,8 +250,8 @@ apr_status_t apr_xlate_open(apr_xlate_t
*convset = NULL;
- topage = handle_special_names(topage);
- frompage = handle_special_names(frompage);
+ topage = handle_special_names(topage, pool);
+ frompage = handle_special_names(frompage, pool);
new = (apr_xlate_t *)apr_pcalloc(pool, sizeof(apr_xlate_t));
if (!new) {
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: status (?) of current iconv breakage
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Jeff Trawick <tr...@attglobal.net> writes:
> Is anybody working on any of this? Am I confused about something?
>
> 1) APRUTIL_EXPORT_LIBS not used in Apache, so httpd won't load on some
> platforms
>
> 2) apr_iconv_inbuf_const hints from apr_hints.m4 not migrated (to
> where?)
>
> 3) APU_CHECK_ICONV_INBUF not working
>
> config.log shows that a warning is generated from the test compile
> but it does not set apu_iconv_inbuf_const on my RH-6.2/glibc-2.1.3
> box
>
> This seems to be because $GCC is not set in the apr-util so the
> APR_TRY_COMPILE_NO_WARNING can't work when using gcc.
>
> Does anyone know of other breakage?
Recently on the Subversion list, Mike Pilato asked Branko Čibej for a
summary what he knows about the current state of iconv breakage. Here
is Brane's response:
From: Branko Čibej <br...@xbc.nu>
Subject: Re: Alpha on Win32 without UTF8 conversion
To: cmpilato@collab.net
CC: dev@subversion.tigris.org
Date: Tue, 23 Jul 2002 04:12:50 +0200
cmpilato@collab.net wrote:
>Brane, if you can (pleeeeease) take the time to summarize briefly the
>problems you know of, and a checklist of whether or not you've got
>solutions for those problems (perhaps pending in mailing list
>archives), I'd be glad to take a stab at picking up where you left
>off.
>
O.K., here's a summary:
* Paths in APR:
o We must have a way to find out what encoding the file names
produced and consumed by APR have, because on WinNT, those
will always be in UTF-8, regardless of the current locale
settings. See my message and resulting thread in dev@apr:
Subject: [PATCH] Determining the character encoding used for paths in APR
* Determining the default locale encoding:
o apr_xlate.h defines APR_LOCALE_CHARSET, which you can pass
to apr_xlate_open to have it figure out the encoding used by
the current locale. The implementation is unix-only. I wrote
a patch for Windows; I'm attaching the relevant bits of that
patch.
o Now that apr_xlate is in apr-util, that patch has to be
broken out and the code moved into APR. I suggested two new
functions, apr_os_locale_encoding and
apr_os_default_encoding, that would replace the
get_locale_charset and get_default_charset in xlate.c.
* Getting a working iconv library
o apr-iconv isn't.
o I still think supporting GNU libiconv is the way to go. See
my mail in dev@subversion:
Subject: Re: Is --enable-utf8 working everywhere?
Message-ID: <3D...@xbc.nu>
Either the solition that detects and builds the
libiconv
sources, or one that detects and links with a pre-compiled
libiconv, would be fine. Note that we wouldn't distribute
any LGPL code, nor make libiconv binaries available -- just
tell users how to build them. For the win32 binaries on the
sownload site, it'd be quite enought to add a link to the
gnu site where the sources are available; it's not as if
we're changing that source.
Please ask if any of this isn't clear.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Index: i18n/unix/xlate.c
===================================================================
RCS file: /home/cvs/apr/i18n/unix/xlate.c,v
retrieving revision 1.28
diff -u -p -r1.28 xlate.c
--- i18n/unix/xlate.c 15 Jul 2002 19:21:01 -0000 1.28
+++ i18n/unix/xlate.c 17 Jul 2002 00:46:12 -0000
@@ -146,9 +146,21 @@ static const char *get_default_charset(v
* defer to get_default_charset().
*/
-static const char *get_locale_charset(void)
+static const char *get_locale_charset(apr_pool_t *pool)
{
-#if defined(HAVE_NL_LANGINFO) && defined(HAVE_CODESET)
+#ifdef WIN32
+ /* ### Yes, this is a hack and doesn't belong in this file.
+ Will fix soonest. --brane */
+ LCID locale = GetThreadLocale();
+ int len = GetLocaleInfo(locale, LOCALE_IDEFAULTANSICODEPAGE, NULL, 0);
+ char *cp = apr_palloc(pool, len + 2);
+ if (0 < GetLocaleInfo(locale, LOCALE_IDEFAULTANSICODEPAGE, cp + 2, len))
+ {
+ cp[0] = 'C';
+ cp[1] = 'P';
+ return cp;
+ }
+#elif defined(HAVE_NL_LANGINFO) && defined(HAVE_CODESET)
const char *charset;
charset = nl_langinfo(CODESET);
if (charset) {
@@ -158,13 +170,13 @@ static const char *get_locale_charset(vo
return get_default_charset();
}
-static const char *handle_special_names(const char *page)
+static const char *handle_special_names(const char *page, apr_pool_t *pool)
{
if (page == APR_DEFAULT_CHARSET) {
return get_default_charset();
}
else if (page == APR_LOCALE_CHARSET) {
- return get_locale_charset();
+ return get_locale_charset(pool);
}
else {
return page;
@@ -236,8 +250,8 @@ apr_status_t apr_xlate_open(apr_xlate_t
*convset = NULL;
- topage = handle_special_names(topage);
- frompage = handle_special_names(frompage);
+ topage = handle_special_names(topage, pool);
+ frompage = handle_special_names(frompage, pool);
new = (apr_xlate_t *)apr_pcalloc(pool, sizeof(apr_xlate_t));
if (!new) {