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

[Nathaniel Smith]

On Wed, May 11, 2016 at 6:58 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
> On Tue, May 10, 2016 at 6:38 PM, Nathaniel Smith <njs at pobox.com> wrote:
>> On Tue, May 10, 2016 at 3:09 PM, Leonardo Rochael Almeida
>> <leorochael at gmail.com> wrote:
>>> On 10 May 2016 at 18:52, Matthew Brett <matthew.brett at gmail.com> wrote:
>>>>
>>>> On Tue, May 10, 2016 at 5:26 PM, Matthew Brett <matthew.brett at gmail.com>
>>>> wrote:
>>>> >> [...]
>>>> >>
>>>> >> This would probably look like:
>>>> >>
>>>> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever Python
>>>> >> calls
>>>> >> this module)
>>>> >>
>>>> >> Before loading _tkagg.so, we use Python level introspection figure out
>>>> >> where
>>>> >> tkinter.so lives
>>>> >>
>>>> >> We add its directory to LD_LIBRARY_PATH
>>>> >>
>>>> >> we import _tkagg.so
>>>> >>
>>>> >> We take its directory back off of LD_LIBRARY_PATH
>>>> >>
>>>> >> Very weird, but I can't see why it wouldn't work, and probably more
>>>> >> reliable
>>>> >> than anything where we try to reimplement the dynamic loader's search
>>>> >> logic
>>>> >> ourselves.
>>>> >
>>>> > Nice - yes - it does work in a first-pass test - I'll look into
>>>> > automating that.
>>>>
>>>> Ah - except I do not believe it is possible to change the linker path
>>>> for Python modules, within the Python process:
>>>>
>>>> http://www.gossamer-threads.com/lists/python/python/393770#393770
>>
>> Doh :-(
>
> Any other suggestions?

One option is to just drop tk support from the wheels, and stick with
Qt or GTK. Super annoying because it would mean we need to sort out
the Qt-or-GTK wheel situation too, but I guess we have to do that
anyway, and this would just move it up the priority list?

Barring that, I guess the plan of converting _tkagg.so to ctypes is
the only option.

I assume the matplotlib devs are very motivated to get linux wheels --
maybe we can convince them to implement this? :-)

> I guess this will be a problem for the external library PEP?

(It's not a PEP)

For the external library proposal on Linux it's annoying but I think
we're okay -- instead of adjusting LD_LIBRARY_PATH we can fall back to
using the "preload trick", like on Windows. Basically exploiting our
old friend this bug:
   https://sourceware.org/bugzilla/show_bug.cgi?id=19884
:-).

And on Windows I know we can use the preload trick, so that's okay.

What I'm really worried about now is OS X -- we need at least one of
these to work: {runtime changes to DYLD_LIBRARY_PATH, the preloading
trick}. Do they? If not then we have a serious problem :-/

-n

-- 
Nathaniel J. Smith -- https://vorpus.org