Hi, On Tue, May 3, 2016 at 4:47 PM, Matthew Brett <[email protected]> wrote: > On Tue, May 3, 2016 at 5:35 AM, Olivier Grisel <[email protected]> > wrote: >>> I tested it with: >>> >>> import matplotlib >>> matplotlib.use('PyQt5') >> >> Typo, this was supposed to read: >> >> matplotlib.use('Qt5Agg') > > Meanwhile, I tried removing (patchelf --remove-needed) the > requirements of _tkagg.so on the vendored libtk, libtcl, and added > back the requirement (patch --add-needed) on general `libtk.so' and > 'libtcl.so'. This removed the segfault and allowed me to display > `plt.range(10)'. I suppose then, that the tk / tcl ABI that we are > using is relatively stable across versions 8.4 (on the docker image) > and 8.6 (on Debian sid). > > Worth experimenting with this - or too much of a hack?
I have experimented with this. It does seem that we can get away with using the system tcl / tk libraries as installed, at least on a couple of Debian systems I have. Now there's a new problem, to do with linux library namespaces. We need the _tkagg.so file to use the same libraries as the Python Tkinter package at run time. There can be more than one tcl / tk version installed on a given system, so, as things stand, we'd need to inspect the Tkinter extension modules to see what they are using, and then work out a way to use those libraries at run time. Here are the questions for the experts out there: * Can anyone think of a way of using the symbol namespace of the tkinter extension modules directly, to pick up the symbols we need rather than re-importing the libraries? * If we do discover which libraries Tkinter is using, what would be a good way of pulling in these libraries at run-time? Cheers, Matthew _______________________________________________ Wheel-builders mailing list [email protected] https://mail.python.org/mailman/listinfo/wheel-builders
