windows side-by-side configuration woes on windows HPC

Nick Touran partofthething at gmail.com
Fri Oct 16 12:14:08 EDT 2009 

Yes, I'll add the report to the bug ticket. As for the msvcr71.dll, the
particular module I'm using was apparently compiled with VS2005, but I'm
currently unable to rebuild it with VS2008 because I don't have the MSSQL
developer headers, etc. So, in an ideal world, I'd compile the module myself
and strip the manifest, or apply the manifest-stripping patch and then just
compile the module, and the msvcr71.dll step would be unnecessary. (Well, in
an IDEAL world I'd not have all these problems because I'd be running on
MySQL, OpenMPI, and a Linux HPC ;)

-nick


On Fri, Oct 16, 2009 at 6:31 AM, M.-A. Lemburg <mal at egenix.com> wrote:

> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20091016/541b6aac/attachment.html>

More information about the Python-list mailing list