This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ntouran
Recipients aheider, cgohlke, christian.heimes, jdetaeye, koen, lemburg, loewis, mhammond, ntouran, zhirsch
Date 2009-10-16.16:26:07
SpamBayes Score 1.499828e-08
Marked as misclassified No
Message-id <1255710371.71.0.264062735901.issue4120@psf.upfronthosting.co.za>
In-reply-to
Content
Just to share my recent experience with this issue: I was attempting to
get Python 2.6 working with py4mpi, matplotlib, and pymssql on a 64-bit
Windows Vista based HPC cluster via x-copy deployment without the charm
of administrative privileges on the server and on my workstation (which
is XP). It wasn't easy, but I got it working. 

I attempted to apply the patch listed here and recompile the packages
that complained about Side-by-side configurations, but got in too deep
while compiling matplotlib on windows (recall I don't have admin
privileges and can't install the prereqs) so I dug deeper.

I found this: http://blog.kalmbachnet.de/?postid=80 which suggests
removing the publicKeyToken attribute from the manifests to force local
DLLs. This would possibly give the same effect as not embedding the
manifests in the first place using the patch. So I went in, using
VS2008, and removed this attribute from the embedded manifests in
python26.dll, python.exe, and the manifest file in C:\python26. I also
copied msvcm90.dll, msvcp90.dll, and msvcr90.dll from the 9.0.21022.8
folder in c:\Windows\WinSxS into c:\Python26. With that, matplotlib
started working, but pymssql still did not.

I then renamed _mssql.pyd to _mssql.dll so that VS2008 could recognize
the manifest, removed the publicKeyToken attribute, and renamed it back
to _mssql.pyd, but it still complained. Finally, using depends.exe from
the internet, I noticed msvcr71.dll was required on my local machine, so
I tried copying it over to the remote machine, into the site-packages
folder. Bam. It worked. So while I don't really consider this a
solution, it definitely worked for what I needed. Any other 3rd party
modules that complain in the future in my weird xcopy-deployment will
undergo manifest-stripping via VS2008 and other dependency checking via
depends.exe. Yay.

By the way, the pymssql was compiled with VS2005, which is why it
requires msvcr71.dll. If I could rebuild it with VS2008, I imagine that
step wouldn't be necessary. While I do have VS2008 on hand, I don't have
MS SQL 2020 Super Awesome Developer Edition, or whatever 3GB package
installs the required header.
History
Date User Action Args
2009-10-16 16:26:12ntouransetrecipients: + ntouran, lemburg, loewis, mhammond, christian.heimes, koen, aheider, zhirsch, jdetaeye, cgohlke
2009-10-16 16:26:11ntouransetmessageid: <1255710371.71.0.264062735901.issue4120@psf.upfronthosting.co.za>
2009-10-16 16:26:09ntouranlinkissue4120 messages
2009-10-16 16:26:07ntourancreate