[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? Bill
