matplotlib

On Tue, Dec 16, 2008 at 2:17 PM, Christopher Barker
<Chris.Barker@...> wrote:

> "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib-0.98.5.1-py2.5.egg/matplotlib/image.py",
> line 19, in <module>
>    from matplotlib import _png
> ImportError:
> dlopen(/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib-0.98.5.1-py2.5.egg/matplotlib/_png.so,
> 2): Symbol not found: _png_destroy_read_struct
>  Referenced from:


Well, at least we have a *different* bug to focus on.  I'll try and
reproduce this somewhere....  I wonder if this is backend dependent
(eg you are using a backend that also links png and something is
getting confused).  Could you try running ::

  import matplotlib.pyplot as plt
  plt.plot([1,2,3])
  plt.show()

with

  > python myfile.py -dAgg
  > python myfile.py -dTkAgg
  > python myfile.py -dWXAgg
  > python myfile.py -dPS

and let me know what you find.

JDH
HDG

On Tue, Dec 16, 2008 at 2:17 PM, Christopher Barker
<Chris.Barker@...> wrote:

> However, once installed, I tried to run it, and got libpng issues --
> aaarrgg!:

Could you also test the mpkg zip file -- I am curious if that shows
the same png problems for you.

JDH

Another note:

I was wrong, if I easy_install the egg without the -macosx from scratch, 
it fails with:

Searching for matplotlib-0.98.5.1-py2.5
Reading http://pypi.python.org/simple/matplotlib-0.98.5.1-py2.5/
Couldn't find index page for 'matplotlib-0.98.5.1-py2.5' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading http://pypi.python.org/simple/
No local packages or download links found for matplotlib-0.98.5.1-py2.5
error: Could not find suitable distribution for 
Requirement.parse('matplotlib-0.98.5.1-py2.5')

But now I just ran:

easy_install matplotlib-0.98.5.1-py2.5-macosx.egg

and it worked just fine -- this is weird!


>   > python myfile.py -dAgg

ImportError: 
dlopen(/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib-0.98.5.1-py2.5-macosx.egg/matplotlib/_png.so, 
2): Symbol not found: _png_destroy_read_struct
   Referenced from: 
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib-0.98.5.1-py2.5-macosx.egg/matplotlib/_png.so
   Expected in: dynamic lookup

>   > python myfile.py -dTkAgg

same error

>   > python myfile.py -dWXAgg

same error

>   > python myfile.py -dPS

same error -- why does it need to use png at all with PS?

 > Could you also test the mpkg zip file -- I am curious if that shows
 > the same png problems for you.

same errors as the egg.

Can you test on PPC?

I recently had a problem with a wxPython extension -- it build 
Universal, but only worked on Intel. It turns out that the wxPython 
binaries were compiled differently on PPC and Intel -- using an older 
version of gcc on PPC (for 10.3 compatibility maybe?). Anyway, it was a 
mess, but we fixed it by compiling the extension separately with a bunch 
of different flags, then lipo-ing the two binaries together.

Could anything funky like that be going on here?

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@...

On Tue, Dec 16, 2008 at 2:25 PM, John Hunter <jdh2358@...> wrote:
dlopen(/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib-0.98.5.1-py2.5.egg/matplotlib/_png.so,
>> 2): Symbol not found: _png_destroy_read_struct
>>  Referenced from:
>
>
> Well, at least we have a *different* bug to focus on.  I'll try and
> reproduce this somewhere....  I wonder if this is backend dependent
> (eg you are using a backend that also links png and something is
> getting confused).  Could you try running ::

Just a quick comment -- the symbol _png_destroy_read_struct is not
defined in the png sources I am using (png_destroy_read_struct is).
Thus it looks like a C++ name mangling issue, probably introduced when
the mpl c++ includes and links against the code.  Just throwing this
out there in case anyone has advice on special flags to use when
building "universal" binaries to prevent name mangling issues.

JDH

On Tue, Dec 16, 2008 at 3:59 PM, John Hunter <jdh2358@...> wrote:

> Just a quick comment -- the symbol _png_destroy_read_struct is not
> defined in the png sources I am using (png_destroy_read_struct is).
> Thus it looks like a C++ name mangling issue, probably introduced when
> the mpl c++ includes and links against the code.  Just throwing this
> out there in case anyone has advice on special flags to use when
> building "universal" binaries to prevent name mangling issues.

I *may*, repeat *may*, have had a breakthrough here.  It appears that
setting the universal flags on the make line is not enough -- they
must actually be exported (as Charlie's original notes indicate).
Please try again with the new OS X binaries at

https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194&release_id=646644

I didn't do any clever renaming of the egg this time -- just focusing
on the png name manging error.

Fingers crossed,
JDH

On Tue, Dec 16, 2008 at 3:17 PM, Christopher Barker
<Chris.Barker@...> wrote:

>>  > python myfile.py -dPS
>
> same error -- why does it need to use png at all with PS?

Chris,

Thanks for all the tests.  The image module uses _png.  Even the
vector backends need raster images.  We could move the import into the
method when it is actually called, since we actually embed the images
directly into the ps and do not go via png.

>> Could you also test the mpkg zip file -- I am curious if that shows
>> the same png problems for you.
>
> same errors as the egg.
>
> Can you test on PPC?

I do have an old, clunky OSX 10.3 machine at home.  A little afraid to
go there :-(

>
> I recently had a problem with a wxPython extension -- it build Universal,
> but only worked on Intel. It turns out that the wxPython binaries were
> compiled differently on PPC and Intel -- using an older version of gcc on
> PPC (for 10.3 compatibility maybe?). Anyway, it was a mess, but we fixed it
> by compiling the extension separately with a bunch of different flags, then
> lipo-ing the two binaries together.
>
> Could anything funky like that be going on here?

Could be -- you can check the Makefile to get a look at the flags I am
using and let me know if you have any suggestions

http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/release/osx/Makefile?view=markup

JDH

>
>
> Please try again with the new OS X binaries at
>
> https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194&release_id=646644
>
Clean install of

	matplotlib-0.98.5.2-py2.5-macosx10.5.mpkg

worked fine for me on OS X 10.5.6 MBP Intel 15" with

	python-2.5.2-macosx.dmg
	numpy-1.2.1-py2.5-macosx10.5.dmg
	wxPython2.8-osx-unicode-2.8.9.1-universal-py2.5.dmg
	ipython-0.9.1-py2.5.egg