Re: [Matplotlib-users] matplotlib FuncAnimation hanging issue
Hi Tony, thanks for the reply. I was using 1.2.0 and just upgraded to 1.2.1 but the problem persists. I ran the example code from the link and it hangs after 350-400 frames. Also, I got an error when running the code as it is posted and had to add: import matplotlib matplotlib.use(Agg) to get it to work. Is this an incorrect setting I'm using? Colin Quoting Tony Yu tsy...@gmail.com: On Sun, May 5, 2013 at 7:12 PM, Colin McAuliffe cjm2...@columbia.eduwrote: Hello all, I'm having an issue with FuncAnimation with ffmpeg. For a small number of frames everything works fine, but for some reason with more than 600 frames the program hangs indefinitely. Is there some kind of frame limit for FuncAmimation or is there a mistake in the arguements I am passing? Hi Colin, Which version of Matplotlib are you running? This sounds similar to a bug addressed by the following change: https://github.com/matplotlib/matplotlib/pull/989 This change has already made it into the current release (v1.2). Best, -Tony -- Colin McAuliffe PhD Candidate Columbia University Department of Civil Engineering and Engineering Mechanics -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] How to make matplotlib use my own libpng over the systemwide
On 05/03/2013 02:41 PM, Ondřej Čertík wrote: Hi, As part of building matplotlib for the one python based distribution [1], I want to always link against our own version of libpng, even if there is some other systemwide version available. I am on linux (Ubuntu). Currently, here is what I am doing: CFLAGS=-I$PNG/include -I$FREETYPE/include -I$FREETYPE/include/freetype2 LDFLAGS=-L$FREETYPE/lib -L$PNG/lib -Wl,-rpath=$PNG/lib $PYTHON/bin/python setup.py build $PYTHON/bin/python setup.py install This *should* work. Can you provide a full build log of a clean build? Mike -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] How to make matplotlib use my own libpng over the systemwide
On Mon, May 6, 2013 at 7:18 AM, Michael Droettboom md...@stsci.edu wrote: On 05/03/2013 02:41 PM, Ondřej Čertík wrote: Hi, As part of building matplotlib for the one python based distribution [1], I want to always link against our own version of libpng, even if there is some other systemwide version available. I am on linux (Ubuntu). Currently, here is what I am doing: CFLAGS=-I$PNG/include -I$FREETYPE/include -I$FREETYPE/include/freetype2 LDFLAGS=-L$FREETYPE/lib -L$PNG/lib -Wl,-rpath=$PNG/lib $PYTHON/bin/python setup.py build $PYTHON/bin/python setup.py install This *should* work. Can you provide a full build log of a clean build? Sure: https://gist.github.com/certik/5528134 The build was produced by the build.sh script, also in the gist. On the line 48 (https://gist.github.com/certik/5528134#file-mpl_log-txt-L48) you can see where our own PNG lib is: [matplotlib] lrwxrwxrwx 1 ondrej cnls 11 May 3 11:48 /auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib/libpng.so - libpng16.so [matplotlib] lrwxrwxrwx 1 ondrej cnls 18 May 3 11:48 /auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib/libpng16.so - libpng16.so.16.2.0 as printed by the line 5 in build.sh: echo Our PNG library: ls -l $PNG/lib/libpng*.so The actual mpl build starts at the line 52 (https://gist.github.com/certik/5528134#file-mpl_log-txt-L52). As you can see, it found the systemwide PNG lib: [matplotlib] OPTIONAL BACKEND DEPENDENCIES [matplotlib] libpng: 1.2.46 and just to verify this, at the line 2636 (https://gist.github.com/certik/5528134#file-mpl_log-txt-L2636) I print: echo The linked PNG library: ldd $PYTHON/lib/python2.7/site-packages/matplotlib/_png.so which gives: [matplotlib] The linked PNG library: [matplotlib] linux-vdso.so.1 = (0x7fffd8bc1000) [matplotlib] libpng12.so.0 = /lib/x86_64-linux-gnu/libpng12.so.0 (0x7f1fd0c0a000) [matplotlib] libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f1fd090a000) [matplotlib] libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f1fd06f3000) [matplotlib] libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f1fd04d6000) [matplotlib] libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f1fd0117000) [matplotlib] libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7f1fcfeff000) [matplotlib] libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f1fcfc03000) [matplotlib] /lib64/ld-linux-x86-64.so.2 (0x7f1fd107e000) So the systemwide png /lib/x86_64-linux-gnu/libpng12.so.0 is linked instead: ondrej@kittiwake:~$ ls -l /lib/x86_64-linux-gnu/libpng12.so.0 lrwxrwxrwx 1 root root 18 Apr 5 2012 /lib/x86_64-linux-gnu/libpng12.so.0 - libpng12.so.0.46.0 as you can see, it is exactly the one as advertised by the mpl build info above. So the mpl build seems consistent, and the bug is that it finds the systemwide version before our own version. Ondrej -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] How to make matplotlib use my own libpng over the systemwide
My understanding is that distutils builds up the commandline arguments for gcc in this order: 1) From Python's Makefile. 2) From environment variables 3) From whatever was added by the setup.py script It looks like you have some extra stuff in (1), namely -L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu You can find the Python Makefile that is being used to source this information here: from distutils import sysconfig sysconfig.get_makefile_filename() You can edit that file, though obviously that's a bit of a hack. I've run into this problem before, and there doesn't seem to be any good way around it -- i.e. there doesn't seem to be a way to insert local environment variables in front of the global Python configuration. Reason number #47 why distutils is a poor build system for C/C++ code. Mike On 05/06/2013 05:03 PM, Ondřej Čertík wrote: On Mon, May 6, 2013 at 7:18 AM, Michael Droettboom md...@stsci.edu wrote: On 05/03/2013 02:41 PM, Ondřej Čertík wrote: Hi, As part of building matplotlib for the one python based distribution [1], I want to always link against our own version of libpng, even if there is some other systemwide version available. I am on linux (Ubuntu). Currently, here is what I am doing: CFLAGS=-I$PNG/include -I$FREETYPE/include -I$FREETYPE/include/freetype2 LDFLAGS=-L$FREETYPE/lib -L$PNG/lib -Wl,-rpath=$PNG/lib $PYTHON/bin/python setup.py build $PYTHON/bin/python setup.py install This *should* work. Can you provide a full build log of a clean build? Sure: https://gist.github.com/certik/5528134 The build was produced by the build.sh script, also in the gist. On the line 48 (https://gist.github.com/certik/5528134#file-mpl_log-txt-L48) you can see where our own PNG lib is: [matplotlib] lrwxrwxrwx 1 ondrej cnls 11 May 3 11:48 /auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib/libpng.so - libpng16.so [matplotlib] lrwxrwxrwx 1 ondrej cnls 18 May 3 11:48 /auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib/libpng16.so - libpng16.so.16.2.0 as printed by the line 5 in build.sh: echo Our PNG library: ls -l $PNG/lib/libpng*.so The actual mpl build starts at the line 52 (https://gist.github.com/certik/5528134#file-mpl_log-txt-L52). As you can see, it found the systemwide PNG lib: [matplotlib] OPTIONAL BACKEND DEPENDENCIES [matplotlib] libpng: 1.2.46 and just to verify this, at the line 2636 (https://gist.github.com/certik/5528134#file-mpl_log-txt-L2636) I print: echo The linked PNG library: ldd $PYTHON/lib/python2.7/site-packages/matplotlib/_png.so which gives: [matplotlib] The linked PNG library: [matplotlib] linux-vdso.so.1 = (0x7fffd8bc1000) [matplotlib] libpng12.so.0 = /lib/x86_64-linux-gnu/libpng12.so.0 (0x7f1fd0c0a000) [matplotlib] libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f1fd090a000) [matplotlib] libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f1fd06f3000) [matplotlib] libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f1fd04d6000) [matplotlib] libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f1fd0117000) [matplotlib] libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7f1fcfeff000) [matplotlib] libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f1fcfc03000) [matplotlib] /lib64/ld-linux-x86-64.so.2 (0x7f1fd107e000) So the systemwide png /lib/x86_64-linux-gnu/libpng12.so.0 is linked instead: ondrej@kittiwake:~$ ls -l /lib/x86_64-linux-gnu/libpng12.so.0 lrwxrwxrwx 1 root root 18 Apr 5 2012 /lib/x86_64-linux-gnu/libpng12.so.0 - libpng12.so.0.46.0 as you can see, it is exactly the one as advertised by the mpl build info above. So the mpl build seems consistent, and the bug is that it finds the systemwide version before our own version. Ondrej -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] How to make matplotlib use my own libpng over the systemwide
On Mon, May 6, 2013 at 3:53 PM, Michael Droettboom md...@stsci.edu wrote:
My understanding is that distutils builds up the commandline arguments for
gcc in this order:
1) From Python's Makefile.
2) From environment variables
3) From whatever was added by the setup.py script
It looks like you have some extra stuff in (1), namely
-L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu
You can find the Python Makefile that is being used to source this
information here:
from distutils import sysconfig
sysconfig.get_makefile_filename()
This gives:
In [1]: from distutils import sysconfig
In [2]: sysconfig.get_makefile_filename()
Out[2]:
'/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/profile/eoul/lib/python2.7/config/Makefile'
You can edit that file, though obviously that's a bit of a hack.
It contains the lines:
CPPFLAGS= -I. -IInclude -I$(srcdir)/Include -I/usr/include/x86_64-linux-gnu
LDFLAGS=-L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu
So indeed this is causing it. I think this comes from building our own
Python, which I do with:
--
#!/bin/bash
set -e
export arch=$(dpkg-architecture -qDEB_HOST_MULTIARCH)
export LDFLAGS=-L/usr/lib/$arch -L/lib/$arch
export CFLAGS=-I/usr/include/$arch
export CPPFLAGS=-I/usr/include/$arch
# Fix for #21:
export HAS_HG=no
./configure --prefix=${PYTHONHPC_PREFIX}
---
And this is a bit of a hack too, Ubuntu specific etc. I think I should
start fixing things here.
It just wouldn't occur to me, that remains of how I built Python would
bite me later when building
matplotlib.
So to test if modifying the Python makefile fixes it, I did:
--- Makefile.old2013-05-06 16:26:25.426440205 -0600
+++ Makefile2013-05-06 16:27:05.282439550 -0600
@@ -73,8 +73,8 @@
# Both CPPFLAGS and LDFLAGS need to contain the shell's value for setup.py to
# be able to build extension modules using the directories specified in the
# environment variables
-CPPFLAGS=-I. -IInclude -I$(srcdir)/Include -I/usr/include/x86_64-linux-gnu
-LDFLAGS=-L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu
+CPPFLAGS=-I. -IInclude -I$(srcdir)/Include
+LDFLAGS=
LDLAST=
SGI_ABI=
CCSHARED=-fPIC
but mpl build system still shows the system one. The _png.so is built with:
[matplotlib] g++ -pthread -shared
-L/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/lib
-L/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib
-Wl,-rpath=/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib
-I/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/include
-I/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include
-I/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include/freetype2
build/temp.linux-x86_64-2.7/src/_png.o
build/temp.linux-x86_64-2.7/src/mplutils.o
build/temp.linux-x86_64-2.7/CXX/IndirectPythonInterface.o
build/temp.linux-x86_64-2.7/CXX/cxxsupport.o
build/temp.linux-x86_64-2.7/CXX/cxx_extensions.o
build/temp.linux-x86_64-2.7/CXX/cxxextensions.o -L/usr/local/lib
-L/usr/lib -lpng12 -lz -lstdc++ -lm -o
build/lib.linux-x86_64-2.7/matplotlib/_png.so
Which in my opinion looks good -- my own version of PNG is offered
first on the gcc command line. But the -lpng12 part spoils it --- that
forces gcc to use the systemone, because my own version is newer.
So I think that part of the problem gets fixed by modifying the Python
Makefile, but the other part of the problem is how to force distutils
to look for my PNG version before the systemwide. Any ideas?
Maybe it is something that is added by the mpl setup.py script.
I've run into this problem before, and there doesn't seem to be any good way
around it -- i.e. there doesn't seem to be a way to insert local environment
variables in front of the global Python configuration. Reason number #47
why distutils is a poor build system for C/C++ code.
This is amazingly broken.
Ondrej
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] How to make matplotlib use my own libpng over the systemwide
Well, we could try a different approach. matplotlib will use pkg-config
to find its dependencies, if available.
If you can get your local libpng to include a libpng.pc (i.e. a
pkg-config information file) and then add your local pkg-config path
(probably
/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/profile/eoul/lib/pkgconfig)
to the PKG_CONFIG_PATH environment variable, it should pick up the right
name for the library as well. If you get that working, you may be able
to avoid setting CFLAGS and LDFLAGS explicitly and the Makefile
modifications.
Mike
On 05/06/2013 06:53 PM, Ondřej Čertík wrote:
On Mon, May 6, 2013 at 3:53 PM, Michael Droettboom md...@stsci.edu wrote:
My understanding is that distutils builds up the commandline arguments for
gcc in this order:
1) From Python's Makefile.
2) From environment variables
3) From whatever was added by the setup.py script
It looks like you have some extra stuff in (1), namely
-L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu
You can find the Python Makefile that is being used to source this
information here:
from distutils import sysconfig
sysconfig.get_makefile_filename()
This gives:
In [1]: from distutils import sysconfig
In [2]: sysconfig.get_makefile_filename()
Out[2]:
'/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/profile/eoul/lib/python2.7/config/Makefile'
You can edit that file, though obviously that's a bit of a hack.
It contains the lines:
CPPFLAGS= -I. -IInclude -I$(srcdir)/Include -I/usr/include/x86_64-linux-gnu
LDFLAGS=-L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu
So indeed this is causing it. I think this comes from building our own
Python, which I do with:
--
#!/bin/bash
set -e
export arch=$(dpkg-architecture -qDEB_HOST_MULTIARCH)
export LDFLAGS=-L/usr/lib/$arch -L/lib/$arch
export CFLAGS=-I/usr/include/$arch
export CPPFLAGS=-I/usr/include/$arch
# Fix for #21:
export HAS_HG=no
./configure --prefix=${PYTHONHPC_PREFIX}
---
And this is a bit of a hack too, Ubuntu specific etc. I think I should
start fixing things here.
It just wouldn't occur to me, that remains of how I built Python would
bite me later when building
matplotlib.
So to test if modifying the Python makefile fixes it, I did:
--- Makefile.old2013-05-06 16:26:25.426440205 -0600
+++ Makefile2013-05-06 16:27:05.282439550 -0600
@@ -73,8 +73,8 @@
# Both CPPFLAGS and LDFLAGS need to contain the shell's value for setup.py
to
# be able to build extension modules using the directories specified in the
# environment variables
-CPPFLAGS=-I. -IInclude -I$(srcdir)/Include
-I/usr/include/x86_64-linux-gnu
-LDFLAGS=-L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu
+CPPFLAGS=-I. -IInclude -I$(srcdir)/Include
+LDFLAGS=
LDLAST=
SGI_ABI=
CCSHARED=-fPIC
but mpl build system still shows the system one. The _png.so is built with:
[matplotlib] g++ -pthread -shared
-L/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/lib
-L/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib
-Wl,-rpath=/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib
-I/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/include
-I/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include
-I/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include/freetype2
build/temp.linux-x86_64-2.7/src/_png.o
build/temp.linux-x86_64-2.7/src/mplutils.o
build/temp.linux-x86_64-2.7/CXX/IndirectPythonInterface.o
build/temp.linux-x86_64-2.7/CXX/cxxsupport.o
build/temp.linux-x86_64-2.7/CXX/cxx_extensions.o
build/temp.linux-x86_64-2.7/CXX/cxxextensions.o -L/usr/local/lib
-L/usr/lib -lpng12 -lz -lstdc++ -lm -o
build/lib.linux-x86_64-2.7/matplotlib/_png.so
Which in my opinion looks good -- my own version of PNG is offered
first on the gcc command line. But the -lpng12 part spoils it --- that
forces gcc to use the systemone, because my own version is newer.
So I think that part of the problem gets fixed by modifying the Python
Makefile, but the other part of the problem is how to force distutils
to look for my PNG version before the systemwide. Any ideas?
Maybe it is something that is added by the mpl setup.py script.
I've run into this problem before, and there doesn't seem to be any good way
around it -- i.e. there doesn't seem to be a way to insert local environment
variables in front of the global Python configuration. Reason number #47
why distutils is a poor build system for C/C++ code.
This is amazingly broken.
Ondrej
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your
Re: [Matplotlib-users] matplotlib FuncAnimation hanging issue
On Mon, May 6, 2013 at 7:09 AM, Colin McAuliffe cjm2...@columbia.eduwrote: Hi Tony, thanks for the reply. I was using 1.2.0 and just upgraded to 1.2.1 but the problem persists. I ran the example code from the link and it hangs after 350-400 frames. Also, I got an error when running the code as it is posted and had to add: import matplotlib matplotlib.use(Agg) to get it to work. Is this an incorrect setting I'm using? Colin Hmm, that's strange: Your problem sounds too similar to be a different bug. Could you copy the error message you got? It might be a clue. Also, what backend are you running? import matplotlib.pyplot as plt print plt.rcParams['backend'] Another possibility (longshot) is that your version of `ffmpeg` may not respect the `-loglevel quiet` flag being passed to suppress output. Maybe you could try running an `ffmpeg` command with and without that flag to see if it works. -Tony -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] How to make matplotlib use my own libpng over the systemwide
On Mon, May 6, 2013 at 6:27 PM, Michael Droettboom md...@stsci.edu wrote: Well, we could try a different approach. matplotlib will use pkg-config to find its dependencies, if available. If you can get your local libpng to include a libpng.pc (i.e. a pkg-config information file) and then add your local pkg-config path (probably /auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/profile/eoul/lib/pkgconfig) to the PKG_CONFIG_PATH environment variable, it should pick up the right name for the library as well. It works!! Thanks a lot. Here I found the same answer as well: http://stackoverflow.com/questions/16227285/unable-to-import-matplotlib-png-pylab If you get that working, you may be able to avoid setting CFLAGS and LDFLAGS explicitly and the Makefile modifications. Indeed. I definitely don't need Python Makefile modifications and here is my polished install script now: export PKG_CONFIG_PATH=$PNG/lib/pkgconfig:$FREETYPE/lib/pkgconfig export LDFLAGS=-L$PNG/lib -Wl,-rpath=$PNG/lib $PYTHON/bin/python setup.py install As you can see, I still need to setup the rpath, but that is to be expected. For the record, here is how _png.o and _png.so end up compiled and linked: gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -I/home/ondrej/repos/python-hpcmp2/opt/png/qhle/include -I/home/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include -I/home/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include/freetype2 -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -DPYCXX_ISO_CPP_LIB=1 -I/usr/local/include -I/usr/include -I/home/ondrej/repos/python-hpcmp2/opt/png/qhle/include/libpng16 -I/usr/local/include -I/usr/include -I. -I/home/ondrej/repos/python-hpcmp2/opt/numpy/hpbc/lib/python2.7/site-packages/numpy/core/include -I. -I/home/ondrej/repos/python-hpcmp2/opt/python/llzf/include/python2.7 -c src/_png.cpp -o build/temp.linux-x86_64-2.7/src/_png.o g++ -pthread -shared -L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/home/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/lib -L/home/ondrej/repos/python-hpcmp2/opt/png/qhle/lib -Wl,-rpath=/home/ondrej/repos/python-hpcmp2/opt/png/qhle/lib -I/home/ondrej/repos/python-hpcmp2/opt/png/qhle/include -I/home/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include -I/home/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include/freetype2 build/temp.linux-x86_64-2.7/src/_png.o build/temp.linux-x86_64-2.7/src/mplutils.o build/temp.linux-x86_64-2.7/CXX/cxx_extensions.o build/temp.linux-x86_64-2.7/CXX/IndirectPythonInterface.o build/temp.linux-x86_64-2.7/CXX/cxxsupport.o build/temp.linux-x86_64-2.7/CXX/cxxextensions.o -L/home/ondrej/repos/python-hpcmp2/opt/png/qhle/lib -L/usr/local/lib -L/usr/lib -lpng16 -lz -lstdc++ -lm -o build/lib.linux-x86_64-2.7/matplotlib/_png.so I think that this looks good. If I need to ever remove the -L/usr/lib/x86_64-linux-gnu parts, then I just fix the Python package. Ondrej -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
