[Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk

Nathaniel Smith njs at pobox.com
Mon Apr 25 16:00:03 EDT 2016

On Apr 25, 2016 10:38 AM, "Matthew Brett" <matthew.brett at gmail.com> wrote:
> Hi,
> I am building matplotlib manylinux wheels:
> The problem is, what to do about the default matplotlib tk optional
> Normally, matplotlib builds against the installed system tk libs :
> https://github.com/matplotlib/matplotlib/blob/master/setupext.py#L1522
> When building a manylinux wheel, we can only build against the tk libs
> / headers on the manylinux docker image, by doing `yum install -y
> tk-devel` before building.
> This means that the tk that matplotlib is built against, is different
> from the one that Python uses with `import Tkinter`.  I suppose that
> is what causes the following, when building matplotlib with tk-devel
> installed:
> >>> import matplotlib
> >>> matplotlib.get_backend()
> u'TkAgg'
> >>> import matplotlib.pyplot as plt
> >>> plt.plot(range(10))
> [<matplotlib.lines.Line2D object at 0x7f2a8e4b4390>]
> >>> plt.show()
> Segmentation fault
> I don't immediately see a good way to deal with this.  Any thoughts?

Maybe obvious, but here's a syllogism:

    matplotlib and python have to agree on which tk libs they are using,
    there are inconsistencies between tk libs on different Linux systems
such that matplotlib must be built against the same tk as it eventually
    we don't really have any option except to disable tk support in
matplotlib manylinux wheels

So I guess the question to focus on are whether those two premises are
actually true. I guess a backtrace on the segfault would help?

Also: how important is tk support? Do we have a fallback? I know that Qt
packaging is something of a mess right now too...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160425/bc1c5978/attachment-0001.html>

More information about the Matplotlib-devel mailing list