Re: [Matplotlib-users] How to make matplotlib use my own libpng over the systemwide

[Michael D. <md...@st...>]

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...@st...> 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 => (0x00007fffd8bc1000)
> [matplotlib] libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0
> (0x00007f1fd0c0a000)
> [matplotlib] libstdc++.so.6 =>
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1fd090a000)
> [matplotlib] libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
> (0x00007f1fd06f3000)
> [matplotlib] libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x00007f1fd04d6000)
> [matplotlib] libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1fd0117000)
> [matplotlib] libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1fcfeff000)
> [matplotlib] libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1fcfc03000)
> [matplotlib] /lib64/ld-linux-x86-64.so.2 (0x00007f1fd107e000)
>
> 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