[matplotlib-devel] os x egg fubar?

John Hunter wrote:

I've posted new eggs and a binary mpkg installer for OS X and a new
tarball. I've tried your egg renaming trick. Let me know how it
goes.

well, when I tried:

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

it again did the sillyness of installing it, then going and downloading the source.

However, I took the "macosx" off the name, and it worked fine:

easy_install matplotlib-0.98.5.1-py2.5.egg

But then it's a bit hard for users to know that it's an OS-X egg! Maybe it could be put on the download site as:

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

and unpack it to one with the shorter name. (even though *.egg files are already zipped!

Perhaps we need to figure out what the heck is wrong with easy_install instead! (Not I want to dig into that code!)

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

>>> import matplotlib
>>> matplotlib.__version__
'0.98.5.1'
>>> import pylab
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib-0.98.5.1-py2.5.egg/pylab.py", line 1, in <module>
     from matplotlib.pylab import *
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib-0.98.5.1-py2.5.egg/matplotlib/pylab.py", line 206, in <module>
     from matplotlib import mpl # pulls in most modules
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib-0.98.5.1-py2.5.egg/matplotlib/mpl.py", line 3, in <module>
     from matplotlib import axes
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib-0.98.5.1-py2.5.egg/matplotlib/axes.py", line 18, in <module>
     import matplotlib.image as mimage
   File "/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: /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib-0.98.5.1-py2.5.egg/matplotlib/_png.so
   Expected in: dynamic lookup

I'm running python 2.5.2 universal framework build, on a PPC running OS-X 10.4

Here is the otool ouput on _png.so:

otool -L _png.so
_png.so:
         /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
         /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10)
         /usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
         /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 47.1.0)

so it's not linked to the dynamic libpng -- hmmm.

-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@...259...

"/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@...259...> wrote:

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

JDH

···

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

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

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 Simple index
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@...259...

> 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 :frowning:

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

JDH

···

On Tue, Dec 16, 2008 at 3:17 PM, Christopher Barker <Chris.Barker@...259...> 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 2:25 PM, John Hunter <jdh2358@...287...> wrote:

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

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:59 PM, John Hunter <jdh2358@...287...> 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.

Please try again with the new OS X binaries at

matplotlib - Browse /matplotlib/matplotlib-0.98.5 at SourceForge.net

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