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

[Matthew Brett]

Hi,

On Wed, May 11, 2016 at 7:26 PM, Nathaniel Smith <njs at pobox.com> wrote:
> 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 :-/

Sorry - writing in haste - but I believe that OSX does have preload
trick. There's something called the "install name" :
http://matthew-brett.github.io/docosx/mac_runtime_link.html#the-install-name
- this is the name the library declares.  I believe (but I am not
sure) that once a library is loaded with a given "install name" then
no further libraries with the same required install name get loaded...

Cheers,

Matthew