[Matplotlib-users] build matplotlib in anaconda environment, wrong png version
Gustavo Goretkin
gustavo.goretkin at gmail.com
Fri Mar 4 10:47:33 EST 2016
If I understood correctly:
$ ldd
~/anaconda2/envs/py3_601/lib/python3.5/site-packages/matplotlib-1.5.1+0.gbe91fac.dirty-py3.5-macosx-10.5-x86_64.egg/matplotlib/_
png.cpython-35m-darwin.so
/Users/goretkin/anaconda2/envs/py3_601/lib/python3.5/site-packages/matplotlib-1.5.1+0.gbe91fac.dirty-py3.5-macosx-10.5-x86_64.egg/matplotlib/_
png.cpython-35m-darwin.so:
libpng16.16.dylib (compatibility version 34.0.0, current version 34.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 60.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1197.1.1)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
2577.0.0)
On Fri, Mar 4, 2016 at 10:36 AM, Thomas Caswell <tcaswell at gmail.com> wrote:
> What does the mac equivalent of
>
> 10:34 $ ldd _png.cpython-35m-x86_64-linux-gnu.so
> linux-vdso.so.1 (0x00007ffc905e3000)
> libpng16.so.16 =>
> /home/tcaswell/.virtualenvs/dd35/lib/libpng16.so.16 (0x00007f6cd496d000)
> libpython3.5m.so.1.0 =>
> /home/tcaswell/.virtualenvs/dd35/lib/libpython3.5m.so.1.0
> (0x00007f6cd447e000)
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f6cd40c4000)
> libm.so.6 => /usr/lib/libm.so.6 (0x00007f6cd3dbe000)
> libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f6cd3ba8000)
> libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f6cd398b000)
> libc.so.6 => /usr/lib/libc.so.6 (0x00007f6cd35e9000)
> libz.so.1 => /home/tcaswell/.virtualenvs/dd35/lib/./libz.so.1
> (0x00007f6cd33d3000)
> libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f6cd31cf000)
> libutil.so.1 => /usr/lib/libutil.so.1 (0x00007f6cd2fcb000)
> librt.so.1 => /usr/lib/librt.so.1 (0x00007f6cd2dc3000)
> /usr/lib64/ld-linux-x86-64.so.2 (0x0000560627d6d000)
>
> give?
>
> On Fri, Mar 4, 2016 at 10:11 AM Gustavo Goretkin <
> gustavo.goretkin at gmail.com> wrote:
>
>> I have a small script that saves a figure as png
>>
>> sudo dtruss -t open python mintest_libpng.py 2> trace.txt
>>
>> I see open syscalls to the following
>>
>> open("/usr/local/opt/libpng/lib/libpng16.16.dylib\0", 0x0, 0x0) =
>> 4 0
>> open("/opt/X11/lib/libpng15.15.dylib\0", 0x0, 0x0) = 4 0
>>
>>
>> I repeated that with the conda-installed version of matplotlib, and I
>> don't see any open syscalls that open libpng (?) Any ideas for building
>> matplotlib from source and installing in a conda environment?
>>
>> On Thu, Mar 3, 2016 at 4:53 PM, Gustavo Goretkin <
>> gustavo.goretkin at gmail.com> wrote:
>>
>>> I just tried to build v1.5.1 from source, with `python setup.py
>>> develop`, where `python` is a python within an anaconda distribution.
>>>
>>> It builds fine, and I can do many things with the library. But when
>>> saving, I see the warning
>>>
>>>
>>>
>>> libpng warning: Application built with libpng-1.6.17 but running with
>>>> 1.5.23
>>>>
>>>
>>> and eventually
>>>
>>> /Users/goretkin/repos/matplotlib/lib/matplotlib/backends/backend_pdf.py
>>> in _writePng(self, data)
>>> 1283
>>> 1284 buffer = BytesIO()
>>> -> 1285 _png.write_png(data, buffer)
>>> 1286 buffer.seek(8)
>>> 1287 written = 0
>>>
>>> RuntimeError: Could not create write struct
>>>
>>>
>>> Indeed, the build script shows
>>>
>>> BUILDING MATPLOTLIB
>>> matplotlib: yes [1.5.1]
>>> python: yes [3.5.1 |Continuum Analytics, Inc.| (default,
>>> Dec
>>> 7 2015, 11:24:55) [GCC 4.2.1 (Apple Inc. build
>>> 5577)]]
>>> platform: yes [darwin]
>>>
>>> REQUIRED DEPENDENCIES AND EXTENSIONS
>>> numpy: yes [version 1.10.4]
>>> dateutil: yes [using dateutil version 2.4.2]
>>> pytz: yes [using pytz version 2015.7]
>>> cycler: yes [using cycler version 0.10.0]
>>> tornado: yes [using tornado version 4.3]
>>> pyparsing: yes [using pyparsing version 2.0.3]
>>> libagg: yes [pkg-config information for 'libagg' could
>>> not
>>> be found. Using local copy.]
>>> freetype: yes [version 2.5.5]
>>> png: yes [version 1.6.17]
>>> qhull: yes [pkg-config information for 'qhull' could
>>> not be
>>> found. Using local copy.]
>>>
>>> Is this a problem with anaconda reporting the wrong paths? Indeed the
>>> version of libpng in this anaconda environment is libpng16, so its right to
>>> build against it. At run time, someone's to blame for loading the wrong
>>> dynamic library.
>>>
>>> goretkin-mbp:lib goretkin$ ls -la ~/anaconda2/envs/py3_601/lib/ | grep
>>>> png
>>>> lrwxr-xr-x 1 goretkin staff 10 Jan 23 14:14 libpng.a ->
>>>> libpng16.a
>>>> lrwxr-xr-x 1 goretkin staff 17 Jan 23 14:14 libpng.dylib ->
>>>> libpng16.16.dylib
>>>> lrwxr-xr-x 1 goretkin staff 11 Jan 23 14:14 libpng.la ->
>>>> libpng16.la
>>>> -rwxr-xr-x 7 goretkin staff 271336 May 26 2015 libpng16.16.dylib
>>>> -rw-r--r-- 7 goretkin staff 360224 May 26 2015 libpng16.a
>>>> lrwxr-xr-x 1 goretkin staff 17 Jan 23 14:14 libpng16.dylib
>>>> -> libpng16.16.dylib
>>>> -rwxr-xr-x 1 goretkin staff 951 Jan 23 14:14 libpng16.la
>>>>
>>>
>>>
>>> $ otool -L ~/anaconda2/envs/py3_601/lib/libpng.dylib
>>> /Users/goretkin/anaconda2/envs/py3_601/lib/libpng.dylib:
>>> libpng16.16.dylib (compatibility version 34.0.0, current version
>>> 34.0.0)
>>> /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version
>>> 1.2.3)
>>> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
>>> version 1.0.0)
>>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>>> version 111.0.0)
>>>
>>>
>>>
>>> Thanks,
>>> Gustavo
>>>
>>>
>>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Matplotlib-users at python.org
>> https://mail.python.org/mailman/listinfo/matplotlib-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20160304/875c579e/attachment-0001.html>
More information about the Matplotlib-users
mailing list