On Mar 13, 2005, at 12:25 AM, Steve Williams wrote:
>> It appears that the Subversion installer sets the APR_ICONV_PATH
>> environment variable which causes other apps using apr-iconv to use
>> (at
>> least under some conditions) Subversion's collection of encoding
>> descriptions. I just encountered the issue while starting to
>> incorporate apr-iconv into log4cxx and was getting an access violation
>> within Subversion's _tbl_simple.so. I haven't been able to track down
>> exactly what blew up yet.
>>
>> I was curious what motivated setting APR_ICONV_PATH and if there might
>> be a way to eliminate the need to do that.
>
> I believe TortoiseSVN gets around this absurdity by patching the iconv
> libraries to avoid using the environment variable.
>
iconv modules compiled using apr-0.9.x are not compatible with
applications build with apr-1.x. The crash is likely occurring when a
passed in apr_pool_t from the 1.x implementation used by the caller is
passed to the uninitialized apr-0.9.x implementation referenced by the
module. The environment variable approach doesn't distinguish between
0.9 and 1.x compatible modules.
In log4cxx, the module approach wasn't desirable since it would make
distribution more complicated and there is vanishingly small need for
users to be able to add additional encodings. Since the app was C++, I
could play namespace tricks to compile all the modules into the main
program (after adding some missing casts needed to get the code to
compile in C++) and then fake out the iconv_dlopen method. See
http://cvs.apache.org/viewcvs.cgi/logging-log4cxx/src/iconv_module.cpp?
rev=1.2&view=log and
http://cvs.apache.org/viewcvs.cgi/logging-log4cxx/apr-iconv
-1.0.1.patch?rev=1.1&view=log for details.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 15 17:06:37 2005