On Mon, Mar 10, 2014 at 10:34:00AM EST, am_d...@fastmail.fm wrote: > > > On Sun, Mar 9, 2014, at 07:21 PM, Cyril Brulebois wrote: > > Jason White <ja...@jasonjgw.net> (2014-03-10): > > > I think I've found it with a quick search of the Mozilla repository. > > > mozilla/accessible/src/atk/Platform.cpp, line 81: > > > > > > 81 #if defined(LINUX) && defined(__x86_64__) > > > 82 libPath.Append(":/usr/lib64:/usr/lib"); > > > > > > If you change line 82 to > > > libPath.Append(":/usr/lib64:/usr/lib:/usr/lib/x86_64-linux-gnu"); > > > and rebuild Mozilla, it might work. > > > > I think that's a very good catch indeed. There are a few other places > > where one can find /usr/lib in *.ccp files in iceweasel, but most of > > them are debug directories, or paths below /usr/lib/mozilla/. > > > > I suspect it would be nice to have a placeholder/#define somewhere so > > that the proper multiarch directory can be injected from debian/rules; > > depending on how easily I can reproduce the issue, I'll try and get a > > working patch and submit the bug report against iceweasel. > > > I appreciate all the helpful replies so far. The thing that seems so > puzzling to me is why this problem does not occur when running in gnome > shell.
Things work properly in GNOME shell because gnome-settings-daemon in conjunction with libatk-adaptor does something to inject the recommended GTK modules into the environment of GTK apps that get launched. I am not sure how this is done, probably an X setting or property somewhere. Libatk-adaptor doesn't *do* anything as such, but it provides a .desktop file that lives in /usr/lib/gnome-settings-daemon-3.0/gtk-modules that gets read by gnome-settings-daemon and acted upon. Luke -- To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140310002115.GA22610@acapella