Building matplotlib from source with libpng (png.h) installed via fink on Mac OS X

#1

Hi,

On my Macbook Pro I use Python 2.6 as provided by the Enthought Python Distribution. I ran into some problem with Axes3D so I decided to upgrade to the latest version from source. While trying that I got a similiar error message as discussed in

http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/msg12938.html

i.e. error: png.h: No such file or directory

In short matplotlib could not find libpng (or png.h from that). I had libpng installed via fink in the usual place /sw/include etc. This seems to be a quite natural choice, so I wondered why matplotlib does not find that out of the box. Following the tips in the above post I looked at basedir in setupext.py For some reason the basedirs for darwin where commented out. Uncommenting the basedirs did the trick for me [1] and matplotlib happily installed with the libpng from fink.

Hope this will help other mac users. Thanks for the great work on matplotlib!

Cheers,

Markus

[1] Here the relevant lines for setupext.py

     'darwin' : ['/sw/lib/freetype2', '/sw/lib/freetype219', '/usr/local',
                 '/usr', '/sw'],
     # it appears builds with darwin are broken because of all the
     # different flags the deps can be compile with, so I am pushing
     # people to :
     # make -f make.osx fetch deps mpl_build mpl_install

     #'_darwin' : [],

#2

2010/8/9 Markus Baden <markus.baden@...287...>:

On my Macbook Pro I use Python 2.6 as provided by the Enthought Python
Distribution. I ran into some problem with Axes3D so I decided to
upgrade to the latest version from source. While trying that I got a
similiar error message as discussed in

http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/msg12938.html

i.e. error: png.h: No such file or directory

In short matplotlib could not find libpng (or png.h from that). I had
libpng installed via fink in the usual place /sw/include etc. This
seems to be a quite natural choice, so I wondered why matplotlib does
not find that out of the box. Following the tips in the above post I
looked at basedir in setupext.py For some reason the basedirs for
darwin where commented out. Uncommenting the basedirs did the trick
for me [1] and matplotlib happily installed with the libpng from fink.

Hope this will help other mac users. Thanks for the great work on
matplotlib!

Thanks for reporting finally a working pure-setup.py installation!

But are you sure it really works, because mixing binary-distributed
and self-compiled packages often leads to import refusal, when the
external libraries (as freetype) are compiled with a different
compiler than Python.

Friedrich

#3

Thanks for the warning. Not really sure. So far I have seen no problems, i.e. can happily plot. How can I make sure that I don't ran into those problems? I usually don't mix packages and just hope that the EPD guys update to Matplotlib 1.0 soon.

Markus

···

On Aug 10, 2010, at 5:34 AM, Friedrich Romstedt wrote:

2010/8/9 Markus Baden <markus.baden@...287...>:

On my Macbook Pro I use Python 2.6 as provided by the Enthought Python
Distribution. I ran into some problem with Axes3D so I decided to
upgrade to the latest version from source. While trying that I got a
similiar error message as discussed in

http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/msg12938.html

i.e. error: png.h: No such file or directory

In short matplotlib could not find libpng (or png.h from that). I had
libpng installed via fink in the usual place /sw/include etc. This
seems to be a quite natural choice, so I wondered why matplotlib does
not find that out of the box. Following the tips in the above post I
looked at basedir in setupext.py For some reason the basedirs for
darwin where commented out. Uncommenting the basedirs did the trick
for me [1] and matplotlib happily installed with the libpng from fink.

Hope this will help other mac users. Thanks for the great work on
matplotlib!

Thanks for reporting finally a working pure-setup.py installation!

But are you sure it really works, because mixing binary-distributed
and self-compiled packages often leads to import refusal, when the
external libraries (as freetype) are compiled with a different
compiler than Python.

#4

2010/8/10 Markus Baden <markus.baden@...287...>:

Thanks for the warning. Not really sure. So far I have seen no
problems, i.e. can happily plot. How can I make sure that I don't ran
into those problems? I usually don't mix packages and just hope that
the EPD guys update to Matplotlib 1.0 soon.

When you can import pylab and do plotting and all then everything is
fine. The mix I mentioned was that of the precompiled EPD (compiled
with, say, compiler 1) and your probably self-compiled freetype2 (with
say, compiler 2). The problem arises if it does not hold compiler 1
== compiler 2. In that case, usually one can compile, I believe since
the functions are marked as "extern", but when making an attempt to
actually load the shared lib (e.g. freetype2), it may fail with some
random "symbol not found" error.

So far, everything okay.

Happy plotting!
Friedrich

#5

Are you on OSX 10.5 or 10.6? I'm asking because it's important for
others when you're on 10.5 because you're using gcc-4.0 then, while
10.6 users have at least for non-Python (distutils) compilations
gcc-4.2 as default.

Friedrich

#6

I'm running Mac OS X 10.5.8.

Markus

···

On Aug 11, 2010, at 6:09 AM, Friedrich Romstedt wrote:

Are you on OSX 10.5 or 10.6? I'm asking because it's important for
others when you're on 10.5 because you're using gcc-4.0 then, while
10.6 users have at least for non-Python (distutils) compilations
gcc-4.2 as default.

#7

2010/8/11 Markus Baden <markus.baden@...287...>:

I'm running Mac OS X 10.5.8.

Ok, that explains why it works to flawlessly. When you would be on
10.6, you would probably run into the problem I mentioned, because the
software is compiled /also/ for 10.5, and hence with gcc-4.0. Lucky
one :wink: - I'm a bit annoyed by this, but it seems, one can load with
gcc-4.2 compiled software gcc-4.0 compiled libraries, but not vice
versa (i.e. load with a gcc-4.0 compiled program like python from EPD
a shared lib compiled with gcc-4.2).

Is the EPD you're using both for 10.5 and 10.6?

Well,
Friedrich