[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index


From: SteveKing <steveking_at_gmx.ch>
Date: 2003-02-24 20:41:06 CET


with the last version (0.18) Subversion delivers
many apr-iconv *.so modules with the windows
version. Those are compiled with VC6 and depend
on MSVCRT.dll. Also the Subversion installer
set the environement variable APR_ICONV_PATH
to the location where those *.so files are copied to.
This will work as long as there is NO other
Subversion client installed or if those clients
are also built with VC6.
As soon as another client built with VS.NET
does the same (copies its *.so files and sets
the environement variable) then the original
Subversion client will probably crash 'cause
*.so files compiled with VS.NET depend
on MSVCR70.dll - and MSVCRT.dll and MSVCR70.dll
in the same process space lead to severe heap
corruption (see posts about the berkeley db
libs built with VC6 and VS.NET).
If the client built with VS.NET does not copy
those *.so files and set the env-variable then
that client will crash (already happened with
mine, and such heap corruption bugs are really
hard to track down!).

I thought about setting that env-variable on
client start and resetting it on exit, but this
won't work if those clients are used the same
time, or if the client crashes (hey, no programmer
is perfect) before resetting the variable.

I'm not sure but I think apr-iconv looks in
the folder ./iconv (below the application folder)
if that env-variable is not set, at least there's
a #define in the source for that.
Would that be a solution to this problem?
Just not set the env-variable and force
the installer to copy those files to the
subfolder "iconv"?


Received on Mon Feb 24 20:42:21 2003

This is an archived mail posted to the Subversion Dev mailing list.