Martin Hauner wrote:
> "D.J. Heap" <email@example.com> wrote:
>> On 10/9/06, Ivan Zhakov <firstname.lastname@example.org> wrote:
>>> The same workaround helps (copying libapr.dll from TSVN). My idea that
>>> there are some conflicts with TSVN iconv (which is build using
>>> vs2005), now I've asked that user to test without TSVN installed.
>>> Ivan Zhakov
>> Hmm, yes, since apr-iconv uses an environment variable for its path,
>> and TSVN uses a different apr-iconv, if we're picking up TSVN's
>> apr-iconv then there is definitely a potential for problems. Is there
>> any other way to specify a path for apr-iconv besides an environment
>> variable? We probably need to keep multiple copies private to the
>> installation they are for.
> In Subcommander I use a small patch to apr-iconv to solve this issue.
> It first looks for an iconv folder in the same place where the binary
> is installed (in this case the iconv dll) before looking at APR_ICONV_PATH.
TSVN uses almost the same patch for apr-iconv. I've also sent that patch
to the apr dev mailing list, explaining why using the APR_ICONV_PATH env
variable is desasterous. But as with most of my patches, they get
ignored. So I keep using my patched version of apr-iconv because I don't
like having problems because of it.
In short, the patch to apr-iconv makes sure that TSVN uses it's own
libraries - only if they get deleted or are for some unknown reason not
accessible, it falls back to using the APR_ICONV_PATH variable.
And with version 1.4.0, TSVN even has renamed the apr libraries to
libaprxxx_tsvn.dll to get out of the dll-hell for good.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Oct 9 17:32:17 2006