On Mar 29, 2005, at 11:13 PM, William A. Rowe, Jr. wrote:
At 10:09 PM 3/29/2005, Curt Arnold wrote:I'm unclear on the proposed resolution. Does it include a mechanism to distinguish apriconv-1 encoding modules from apriconv-0 modules either by changing the module signature or name?
I believe we should do that, too. But it seems that some want us to use an 'external' iconv implementation, at least, as of the next major release of apr-util. With the files residing in /apriconv-1/*.so I'm less concerned with the signature.
Are you expecting the apriconv-1 directory to be on the PATH or LD_LIBRARY_PATH or relative to a directory on the PATH or LD_LIBRARY_PATH? If it is on the PATH or LD_LIBRARY_PATH, then this is the continued possibility of collision with modules from other iconv implementations, if it is relative to an directory on the path, then I would expect that you would need add a decent amount of complexity to accomplish that. I would think it may be simpler to have modules named apriconv-1-ENCODING.so or .dll and have dlopen or LoadLibrary find them with their existing library search mechanisms, but I could understand if that was undesirable for other reasons.
Without some mechanism to distinguish encoding modules, it really doesn't matter what order the paths are evaluated? If there is a mechanism, it shouldn't hurt to evaluate APR_ICONV_PATH first?
Of course it would, because we would still have to iterate multiple .so files to find the correct one. This is a huge performance hit.
So let me inquire - have you authored a custom (charset).so file, or intend to do so?
No, I have no intention to do that. At this point, the resolution to the issue does not effect log4cxx since it will continue to hack apriconv to embed the encodings into log4cxx.dll and liblog4cxx.so. You need to do what is right for httpd and/or Subversion.
Again, the consensus on list was that apr-iconv was an implementation-internal detail of apr-util. With the next release, implementors/users are expected to install the directory apriconv-1 in parallel to apriconv-1.so [.dll]. APR_ICONV_PATH would be searched last, to pick up those exceptions/custom charset modules. We wouldn't hit iconv/ at all (unless the user asks us to through APR_ICONV_PATH.
Since Subversion sets APR_ICONV_PATH, there is still the possibility of finding an apriconv-0 encoding module if the installation is damaged (or the developer decides not to distribute some obscure encoding) or a new encoding gets added to Subversion and/or apriconv-0.
So I'm confused if this solution doesn't resolve the issues of all users. Please explain further.
On your point of avoiding conflicts by changing the signature, yes I would be -happy- to entertain a patch, if you want to post one in the next day. I'll be putting together my changes tomorrow eve, and would be easily able to integrate your suggestion if you care to offer the patch. I don't see it as a substitute for searching for the right file, but I see it as added security against loading the wrong module.
By changing the signature, I meant changing the value of ICMOD_UC_CCS and ICMOD_UC_CES (currently 0x100 and 0x101). I don't know if this method of module identification is used elsewhere and if so, what other values are currently in use. If the encoding modules can't be distinguished by name, I think it is essential that they have a different magic value. Otherwise, you are just reducing the chances of a catastrophic failure by checking APR_ICONV_PATH last, not eliminating it.
Putting myself in the position of the developer of some hypothetical app (and I couldn't have an iconv2 based solution), I would prefer that apriconv-1 encoding modules be named something like "apriconv-1-utf-8.dll" or "libapriconv-1-utf-8.so" and located using the established library search algorithms in dlopen or LoadLibrary. In deployment, these would likely be placed in the same directory as aprutil-1.dll or libaprutil-1.so or the executable if linked against a static aprutil-1. APR_ICONV_PATH could be ignored. If the user really wanted a new encoding, they could either place it in an already searched directory or add the directory to PATH or LD_LIBRARY_PATH.
However, it would be good if we could get some comment from a Subversion developer.
