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: Collision with Subversion when using apr-iconv on Windows
Date Wed, 16 Mar 2005 22:23:10 GMT
[Proposed solution enclosed]

At 10:07 AM 3/15/2005, Curt Arnold wrote:
>iconv modules compiled using apr-0.9.x are not compatible with  
>applications build with apr-1.x.  

As defined.  There is no apr 0.x apr 1.x apr 2.x compatibility.

Within apr n.x all apr n.y versions are backward compatible.

>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.

Yes the arguments changed.

Yes the envvar approach seems to fail us here.

>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.

Sounds like a variant build for your application was a solution 
to this specific incident, but doesn't solve the problem.

It seems that we need a few things;

 * find the iconv .so files.

 * segregate the iconv .so files by apr verison.

It seems the best solution is;

1. do not presume apr-iconv .so's are related to iconv, since
   a natively cygwin build of iconv would clash.

2. deposit apr-iconv 0.9 files into the iconv/ subdirectory 
   in parallel to libaprutil.dll / libapriconv.dll

3. deposit apr-iconv 1.x files into an apriconv.1 subdirectory
   in parallel to libaprutil-1.dll / libapriconv-1.dll

4. for both apr-iconv 0.9 and 1.x, given an unpathed module
   file name, grab the absolute path of libapriconv[-1].dll,
   and append iconv/ or apriconv-1/ to that path.

5. continue to support the envvar as an alternate means,
   which is not endorsed, until the release of apr 2.0

apr supports parallel installations of apr 0.x and 1.x, but
not of multiple flavors within 0.x and 1.x.  These two specific
path names will help us segregate apr-0 and apr-1 loadable
iconv mapping modules, without clashing.

The only question for debate is if we want apr-0 to drop the
files into iconv/ or apriconv/.  There is no difference for
httpd, log4cxx etc, but for installing in /windows/system32
or another common path, this could present a conflict.

Comments/suggestions on this solution?


View raw message