Hi, On Wed, May 11, 2016 at 7:26 PM, Nathaniel Smith <[email protected]> wrote: > 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 :-/
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 _______________________________________________ Wheel-builders mailing list [email protected] https://mail.python.org/mailman/listinfo/wheel-builders
