windows side-by-side configuration woes on windows HPC
M.-A. Lemburg
mal at egenix.com
Fri Oct 16 09:31:05 EDT 2009
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 <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/
>>
>
--
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/
More information about the Python-list
mailing list