apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Okay, two questions for Bill Rowe
Date Thu, 18 Jul 2002 22:07:26 GMT
At 04:23 PM 7/18/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
>William A. Rowe, Jr. wrote:
>>>    - What's status on the move of apr_xlate* to apr-util?
>>Finished, with the exception of the APR_CHECK_ICONV_INBUF
>>m4 macro that tests for the iconv prototype differences, and one
>>more hack to use our apr_* namespace protected entry points
>>from xlate.c if APR_HAS_APR_ICONV is toggled.  We also need
>>that symbol set up in apu or apu_private.
>>The first macro sticks the #define APR_ICONV_INBUF_CONST 1
>>into apr_private.h which we don't see inside of apu_private.h, so
>>we can't pick it up inside of apr-util/xlate/xlate.c.
>>If someone who groks m4 much better than I would get this inserted
>>into apu_private.h from apu_private.h.in ... we would be done with the
>>new unix / using installed xlate problems.
>Can you try the attached patch? It moves libiconv detection from APR to 
>APR-util, and tweaks things so that APR_ICONV_INBUF_CONST appears in 
>apu_config.h. I left the APR_CHECK_ICONV_INBUF macro in apr_common.m4, but 
>that could be moved to the new apu-iconv.m4 (and renamed to 

I can't easily test right now.  Try in on the OS-X box later, but if someone
beats me to it, and commits this before I can, great!

Please tell me that apu-iconv.m4 would reside in apr-util.  A user that
doesn't want to download apr-iconv shouldn't run into any problems
if they build apr and apr-util.

>I don't know what to do about apr_hints.m4, which sets teh value of 
>APR_ICONV_INBUF_CONST on AIX and Solaris. I don't want to include it in 
>APR-util's configure.

Yea, I hear you.  No ideas from me.

>I don't have a Unix machine handy, unfortunately, so I can't test this 
>right now.

Same problem here, hoping someone is willing to pitch in.

View raw message