On Wed, May 11, 2016 at 6:58 AM, Matthew Brett <[email protected]> wrote: > On Tue, May 10, 2016 at 6:38 PM, Nathaniel Smith <[email protected]> wrote: >> On Tue, May 10, 2016 at 3:09 PM, Leonardo Rochael Almeida >> <[email protected]> wrote: >>> On 10 May 2016 at 18:52, Matthew Brett <[email protected]> wrote: >>>> >>>> On Tue, May 10, 2016 at 5:26 PM, Matthew Brett <[email protected]> >>>> 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 _______________________________________________ Wheel-builders mailing list [email protected] https://mail.python.org/mailman/listinfo/wheel-builders
