bzr 1.6.1/win32: hard crash because wrong libapr.dll is loaded

[Mark Hammond]

> So I've been trying to build the bzr-svn extension so we can get
> another
> full installer for win32. And it turns out that the Subversion guys
> don't have their act completely in sync.
> 
> Specifically, "ebswift" seems to build the Setup-Subversion-*.msi
> files,
> and he builds "libapr-1.dll" et al. However he does not give you .lib
> files to go along with the .dll files that are installed.

AFAIK, we should be fully independent of any SVN dlls that may have been installed - we ship the DLLs we need.

> So if you download the svn-win32-1.5.3_dev.zip file (built by djh) to
> get the .lib files, it turns out that those seem to build libapr.dll.
> And you end up in the unfortunate situation that you don't *have* a
> libapr.dll because libapr-1.dll was installed into C:\Program
> Files\Subversion\bin

I get libapr.dll from the 'svn-win32-1.5.2\bin' directory, which was populated from svn-win32-1.5.2.zip (although it appears 1.5.4 is now out).  Both svn-win32-1.5.2.zip and svn-win32-1.5.2_dev.zip are unpacked into the same directory giving matching headers, libs and DLLs.

> For now, it seems the answer is "don't install SetupSubversion" and
> only
> use the dlls available in the svn-win32-1.5.3.zip. (djh also supplies
> the .dll files to go with his .lib, but he doesn't build an installer
> for them.)
> 
> The other problem is getting your path correct, because -1.5.3.zip
> provides newer versions of libraries like libeay.dll than you may have
> elsewhere. (Well at least than *I* have elsewhere.)

I don't quite understand why bzr-svn is attempting to pull the DLLs from elsewhere on your path and not from the copies we install next to bzr-svn itself.

> In the end, I did get it to work if I only use the .zip files, I
> manually chmod +x the .dll files (probably only matters if you use
> cygwin to unzip), and then insert that 'bin' directory as the first
> thing in my path.

Ah - you are talking about getting things working from a source build where the required DLLs are *not* automatically next to the binaries?

Mark