bzr 1.12rc1 released

[Mark Hammond]

On 12/02/2009 9:06 AM, John Arbash Meinel wrote:
>> In short, it still complains about subvertpy, but now it also throws a
>> Windows dialogue complaining about a missing procedure entry point in
>> a dll. [This is with the 'standalone .exe' installer]
>>
>> DJ
>
> Hmm... I confirmed that 'subvertpy' is bundled in library.zip. I haven't
> seen the missing procedure entry point, though I would guess that it is
> a version-of-OS used to compile the dlls, and some system DLL is
> accidentally getting pulled in. (We explicitly forbid a couple dlls for
> this reason, we may just be missing one that subvertpy pulled in.)

A quick look shows that error is thrown by an attempt to import 
subvertpy by bzr-svn.  Unfortunately, bzr-svn catches the import error 
and re-throws its own, so exactly which module is failing isn't clear, 
but subvertpy has the same 3 .pyd files bzr-svn had, which still depend 
on the svn and apr DLLs in the same way.

I just tested bzr-setup-1.12rc1-2 on a fairly clean Vista install and it 
works fine for me.  However, while our .pyd files don't depend on 
msvcrt.dll, the svn dlls *do*, and googling for that symbol shows that 
some early Windows operating systems certainly don't have that symbol. 
I *think* this is an artifact of how the svn binaries are built (we use 
pre-built svn binaries).

I'm not completely clear on what versions of msvcrt.dll exist out there, 
other than an MS KB article stating that the DLL is now owned by the 
operating system rather than by the C compilers, even though earlier 
some C compilers did create references to this DLL.  I suspect the 
ultimate solution is to build the svn binaries ourselves or try and 
locate some pre-built and which link against the same msvc dll python 
itself depends on - or if ones against vs2008 are available instead, 
consider moving the binary world to Python 2.6.

On the other hand, I see no reason to believe this problem was 
introduced by the new bzr-svn architecture - is it possible to test 
earlier bzr (1.10 or 1.11) binaries and see if the same problem exists? 
  If it doesn't, then it would appear I'm barking up the wrong tree...

Cheers,

Mark