Nick Touran wrote: > 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.
Thanks for your report. Could you add a summary to the ticket I mentioned below ? > 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. What I don't understand in your description is why the msvcr71.dll was needed. It's usually not a good idea to mix VC runtime in a single process and since Python requires the VC 90 DLLs, it's likely safer to recompile the extension in question using Python 2.6 and VS 2008. > -nick > > On Mon, Oct 12, 2009 at 2:41 PM, M.-A. Lemburg <m...@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 <m...@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/ >> > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 16 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/ -- http://mail.python.org/mailman/listinfo/python-list
