On 08/14/2016 02:52 AM, Enno Borgsteede wrote: > Op 23-07-16 om 18:45 schreef Michael Torrie: >> On 06/29/2016 12:48 PM, Enno Borgsteede wrote: >>> I know how to compile a GTK version myself, and it's no big issue to add >>> log statements either, but I don't want to replace the system GTK+ >>> version 2, because many other applications still depend on it, and I >>> don't want to corrupt my whole system. So, what I like to know is how I >>> can push Python to work with a hacked GTK+ version 2 that sits in my >>> home folder. >> You can use the LD_LIBRARY_PATH environment variable to have Linux load >> your custom debugging GTK libraries. No need to overwrite the system >> libraries. > Do you know if this will help for Python too? It calls GTK+-2 via a > wrapper called PyGTK, I think, and I don't know whether that wrapper's > bindings look at the LD_LIBRARY_PATH variable. That's a good question! I'm not sure. I assume it would since pygtk uses some C code to connect with GTK+, which probably is linked directly to the GTK .so files, rather than dynamically loading them at runtime. > > That said, I haven't been able to reproduce my problems with a simple C > program yet, so proving that what I see in Mint 18 or ubuntu 16.04 is > really caused by GTK 2.24.30 may still be quite difficult. > > For now, it's easier for me to just stick with Mint 17.3 as long as that > is supported well. I might convert to a newer version if I knew that > someone else might help me with this GTK issue, but it looks like I'm > the only one complaining now, and I don't have the skills to work on GTK > 2 yet, nor much time. _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
