windows side-by-side configuration woes on windows HPC
Nick Touran
nick_t1 at partofthething.com
Wed Oct 14 17:41:19 EDT 2009
I've made enough progress to get my setup working! I attempted to apply the
patch and recompile the packages that complained but got in too deep while
compiling matplotlib on windows (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 W.ith 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.
-nick
On Mon, Oct 12, 2009 at 2:41 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> Nick Touran wrote:
> > It is indeed a pain. I would really like a work-around. Matplotlib is
> > supposed to be immune to this nowadays but it's not. Nor are some other
> > third-party modules. Did they break with the new release? (2.6.3?)
>
> The main problem appears to be that the the MS VC9 compiler defaults
> to embedding a dependency on the MS VC90 CRT DLL into extension modules:
>
> <dependency>
> <dependentAssembly>
> <assemblyIdentity type="win32" name="Microsoft.VC90.CRT"
> version="9.0.21022.8"
> processorArchitecture="x86"
> publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
> </dependentAssembly>
> </dependency>
>
> Unless you have installed the CRT runtime DLLs installed system-wide,
> this will require the DLLs to be installed next to the extension
> module DLL or PYD file... and that even though the Python process
> itself will already have loaded the DLL from the Python directory.
>
> A work-around is attached to the ticket as patch.
>
> Even though a fix for distutils is planned in 2.6.4, this type of
> problem will pop up for all kinds of software using VC90-based DLLs
> as plugins, so it's probably better to just install the CRT runtime
> DLLs in the WinSxS directory using the CRT installers:
>
> x86:
>
> http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en
>
> x86_64:
>
> http://www.microsoft.com/downloads/details.aspx?familyid=BA9257CA-337F-4B40-8C14-157CFDFFEE4E&displaylang=en
>
> > On Thu, Oct 8, 2009 at 1:12 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> >
> >> Nick Touran wrote:
> >>> Copying my local copy of Python 2.6 to a Windows HPC 2008 system is
> >> giving
> >>> dll side-by-side configuration errors for some third-party packages
> >>> (matplotlib, pyMSSQL, in particular). I understand that there is a
> >> tradition
> >>> of Python supporting XCOPY deployment, and would really like to be able
> >> to
> >>> just copy my C:\python26 folder to the network drive and have it run on
> >> the
> >>> server.
> >>>
> >>> I got around a related issue (http://bugs.python.org/issue4566) just
> by
> >>> upgrading to 2.6.3 and was able to import socket and mpi4py and
> >> everything,
> >>> except matplotlib and pyMSSQL, that is.
> >>>
> >>> I also understand that if I were to install the MS Visual Studio 2008
> >>> redistribution package on the server that everything would be fine
> >> because
> >>> the modules just can't find the proper C run-time DLL. The problem with
> >> that
> >>> is two-fold: I don't have admin rights on the machine and there are
> over
> >>> 1000 machines on the cluster and I don't think the admin is going to
> >> install
> >>> that on all of them.
> >>>
> >>> So is there any way to set an environmental variable or something to
> get
> >>> these packages to know where to find the proper msvcr90.dll, akin to
> >> setting
> >>> LD_LIBRARY_PATH in Linux? Is there another solution?
> >>
> >> I assume this is related to this new problem:
> >>
> >> http://bugs.python.org/issue4120
> >>
> >> Manifests were meant to solve some of the DLL mess... apparently they
> >> cause even more grief.
> >>
> >> --
> >> Marc-Andre Lemburg
> >> eGenix.com
> >>
> >> Professional Python Services directly from the Source (#1, Oct 08 2009)
> >>>>> Python/Zope Consulting and Support ... http://www.egenix.com/
> >>>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
> >>>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
> >> ________________________________________________________________________
> >>
> >> ::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
> >>
> >>
> >> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
> >> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
> >> Registered at Amtsgericht Duesseldorf: HRB 46611
> >> http://www.egenix.com/company/contact/
> >>
> >
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Oct 12 2009)
> >>> Python/Zope Consulting and Support ... http://www.egenix.com/
> >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
> >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
> ________________________________________________________________________
>
> ::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
>
>
> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
> Registered at Amtsgericht Duesseldorf: HRB 46611
> http://www.egenix.com/company/contact/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20091014/fa0b8167/attachment.html>
More information about the Python-list
mailing list