On the surface, Curt's solution would break our compatibility rules.
But I think we can deviate in this instance;
the modules in iconv/*.so are compiled by the apr-iconv project
itself. If we change both apr-iconv and its modules to now
disambiguate the 0.9 and 1.0 modules, and we expect users to
install the iconv/*.so files that match libiconv.[so|dll],
have we broken compatibility?
Second, clearly, we must respect APR_ICONV_PATH, but we can do so
after considering APR_ICONV1_PATH and the path of the iconv module
itself, true?
In fact, my gut tells me:
1. take our path to libapriconv-1.dll on Win32, and suffix a new
"apriconv.1/" directory to it. Search here first. It's both
explicit, it's the internal expectation of apr-iconv, and
applies the principal of least surprise.
for users who don't follow the apriconv.1/ convention;
2. take the user's given APR_ICONV1_PATH, if specified, to help
resolve where they chose to locate the iconv files.
and for users who haven't done anything since 0.9.x...
3. take the given APR_ICONV_PATH, if specified. Curt's proposal
to change the signature should help avoid loading invalid .so
modules and dying in a segfault. The module would simply not
be found.
On unix and other platforms where we can't determine the actual
path of the libapriconv-1.so file, life would go on, and we would
follow steps 2 and 3 above.
Does this seem rational to everyone?
At 07:51 PM 3/16/2005, Curt Arnold wrote:
>On Mar 16, 2005, at 7:32 PM, Justin Erenkrantz wrote:
>>If you are adding a symbol, yes, it'd be 1.1.0. But, under our compatibility
>>rules, it'd have to retain APR_ICONV_PATH as a define in addition to
>>APR_ICONV1_PATH. -- justin
>
>Unfortunately the problem is that APR_ICONV_PATH may find you incompatible
>(0.9.x) modules and if you attempt to use them, you die a most horrible death.
> Either the existing path needs to be ignored or there needs to be a method of
>detecting 0.9.x encoding modules and refusing to load them.
>
>One possibility would be to add use difference values for ICMOD_UC_CCS and
>ICMOD_UC_CES (currently 0x100 and 0x101) so that 0.9.x modules would not be
>recognized as valid encoding modules for a 1.0.x implementation. That would
>also have the benefit of APR 1.x modules not crashing a 0.9.x implementation.
>
>As it stands it is a pretty horrible bug. If you have an app that uses
>apr-iconv-1.x, it will work fine until Subversion is installed and all things
>start crashing.
>
>
