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.old 2013-05-06 16:26:25.426440205 -0600
> +++ Makefile 2013-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
