Dan Stromberg <strom...@gmail.com> added the comment:
On Sun, Oct 2, 2011 at 3:49 PM, Nadeem Vawda <rep...@bugs.python.org> wrote:
>
> Nadeem Vawda <nadeem.va...@gmail.com> added the comment:
>
> 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.
----------
Added file: http://bugs.python.org/file23300/unnamed
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________
<br><div class="gmail_quote">On Sun, Oct 2, 2011 at 3:49 PM, Nadeem Vawda <span
dir="ltr"><<a
href="mailto:rep...@bugs.python.org";>rep...@bugs.python.org</a>></span>
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
Nadeem Vawda <<a
href="mailto:nadeem.va...@gmail.com";>nadeem.va...@gmail.com</a>> added the
comment:<br>
<br>
</div>Thanks for investigating the Windows situation.<br>
<div class="im"><br>
> - liblzma can't be compiled by Visual Studio: too many C99 isms,
mostly<br>
> variables declared in the middle of a block. Â It's doable for sure,
but it's a<br>
> lot of work.<br>
<br>
</div>I don't think that creating our own MSVC-friendly fork of liblzma is
really an<br>
option. Over and above the work of porting it in the first place (and all
the<br>
opportunities for bugs to creep in along the way), we'd also have to worry
about<br>
keeping up to date with upstream changes. I believe we currently do
something<br>
similar with libffi (for ctypes), and the impression I've gotten is that
it's<br>
caused a lot of trouble.</blockquote><div><br></div><div>It's much better
to contribute patches upstream.</div><div>Â </div><blockquote
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex;">
<div class="im">
> - The way recommended by XZ is to use a precompiled liblzma.dll; Then
it<br>
> should be easy to build an extension module, but its would be the first
time<br>
> that we distribute an extension module which needs a non-system DLL. Â Is
it<br>
> enough to copy it next to _lzma.pyd? Â Is there some work to do in the<br>
> installer?<br>
<br>
</div>I would guess that this is sufficient, but my knowledge of how Windows
DLLs work<br>
is minimal. Could someone with more platform knowledge weigh in on whether
this<br>
would work (and if there are any problems it might
cause)?</blockquote><div><br></div><div>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.</div>
<div>Â </div></div>-- <br>Dan Stromberg<br>
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
