On Sun, Oct 2, 2011 at 3:49 PM, Nadeem Vawda
<report@bugs.python.org> wrote:
Thanks for investigating the Windows situation.
> - liblzma can't be compiled by Visual Studio: too many C99 isms, mostly
> variables declared in the middle of a block. It's doable for sure, but it's a
> lot of work.
I don't think that creating our own MSVC-friendly fork of liblzma is really an
option. Over and above the work of porting it in the first place (and all the
opportunities for bugs to creep in along the way), we'd also have to worry about
keeping up to date with upstream changes. I believe we currently do something
similar with libffi (for ctypes), and the impression I've gotten is that it's
caused a lot of trouble.
It's much better to contribute patches upstream.
> - The way recommended by XZ is to use a precompiled liblzma.dll; Then it
> should be easy to build an extension module, but its would be the first time
> that we distribute an extension module which needs a non-system DLL. Is it
> enough to copy it next to _lzma.pyd? Is there some work to do in the
> installer?
I would guess that this is sufficient, but my knowledge of how Windows DLLs work
is minimal. Could someone with more platform knowledge weigh in on whether this
would work (and if there are any problems it might cause)?
I've not done much with windows dll's, but I've heard they're pretty similar to AIX shared libraries which I've done some work with. AIX shared libraries don't deal with versioning well - if you have two version of the same library on a system, you have to pop them into two different loader domains, or suffer unresolved externals at runtime. Then your applications are in of the two loader domains, and if they're in the wrong one, you again suffer unresolved externals at runtime.