Thanks again for all your work on this.  I moved my old minGW and installed
MinGW-5.1.3, and was already running the others--except numpy, I have the
latest version from svn, which I compiled and built fine after building
atlas.  I checked out matplotlib from svn and did the same as you
--I didn't try using the importlib batch file--I have a libpython25.a--so,
after changing the profile24.bat to profile25.bat with appropriate path
changes and your modifications to setup.py, I built it.  I then installed
it--no problems yet.  I then tried to use it with embedding_in_wx4.py and
python crashes and burns.  I find that it crashes with the same LazyValue
error. Something similar happened to one of my colleagues who tried building
with visual studio instead of mingw.  He's given up and is now running it on
his Mac.  Sadly, I don't have that option.  Does anyone else have any ideas?

Thanks,
William

On 8/2/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
> Well, the good news is that I was able to get it to compile and run the
> wxPython backend on Windows.  The bad news is that my symptoms are different
> enough from yours that I'm not sure this will help you.
>
> I started with a reasonably clean Windows XP SP2 machine with no
> development tools on it.  I installed (using the standard binary installers)
> the most recent stable releases of the following:
>
> - Python 2.5.1 (python.org)
> - wxPython-2.8.4.0
> - numpy-1.0.3
> - MinGW-5.1.3 (selecting the "current" release option)
> - MSys-1.0.10
>
> I checked out the latest matplotlib from svn (r3662).
>
> I downloaded and uncompressed win32_static from here:
> http://matplotlib.sourceforge.net/win32_static.tar.gz
>
> I did not do the pexports step, as I don't think MinGW requires it any
> longer.
>
> I updated profile24.bat to point at my new Python 2.5 (this should
> probably be added to win32_static when someone gets a chance).
>
> I then built and installed using:
>
> python setup.py build --compiler=mingw32 install
>
> (Note that I didn't build and use the Windows installer as the
> instructions suggest -- I doubt that makes a difference, though).
>
> It built fine the first time.
>
> Then I ran into problems.  When importing certain extension modules
> (ft2font, _transforms etc.), but not others (ttconv), I got a dialog with
> the error message:
>
>   "The procedure entry point _ctype could not be located in
> the dynamic link library msvcr71.dll"
>
> ...and then the module would fail to load.
>
> This is quite different from what William was seeing, since for him the
> modules were obviously loading and then failing in the initialization code.
>
> Googling tells me that this is because libstdc++ (specifically the
> <string> and <iostream> stuff) depends on _ctype for determining the types
> of various ASCII characters, which was in msvcrt.dll but was removed from
> msvcrt71.dll.  Python2.5 is built with and therefore requires its
> extensions to link to msvcrt71.dll, so that's what you get by
> default.  Fortunately, it doesn't seem to hurt to link to both.  I added the
> following to setup.py, right before the final "distrib = setup(..."
> section:
>
>     from setupext import get_win32_compiler
>     if sys.platform == 'win32' and get_win32_compiler() == 'mingw32':
>         for module in ext_modules:
>             module.libraries.append("msvcrt")
>
> After this change, I was able to run embedding_in_wx4.py and get a window
> with a plot in it.  Everything *seems* to be in order.
>
> William, I'm really curious if the above fix solves your problem.  I
> probably shouldn't spend too much more time on this myself, as Windows isn't
> a very common platform for us (by that I mean my employer, STScI, not
> matplotlib as a whole).  If I can admit selfishness, I really just wanted to
> make sure I hadn't hosed anything with my recent setup.py changes.  I
> think that has been ruled out, and instead we now have what looks like a big
> amorphous configuration-difference problem.
>
> Cheers,
> Mike
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Reply via email to